=== phoenix24_ [n=phoenix2@59.176.13.153] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [04:15] *yawn* === phoenix24 [n=phoenix2@59.176.7.241] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === juergbi [n=juerg@80-219-18-22.dclient.hispeed.ch] has joined #upstart === JohnFlux [n=JohnFlux@konversation/developer/JohnFlux] has joined #upstart === tale [n=tale@207.235.54.1] has joined #upstart === phoenix24 [n=phoenix2@59.176.27.187] has joined #upstart === rawler [n=ulrik@c-7b4ee155.98-2-64736c13.cust.bredbandsbolaget.se] has joined #upstart === rawler [n=ulrik@c-7b4ee155.98-2-64736c13.cust.bredbandsbolaget.se] has joined #upstart === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart === Keybuk had some interesting thoughts today [08:04] oh? [08:06] so the problem I've been having is trying to understand how to define when a job is running [08:06] and also define for instance jobs when instances are spawned and destroyed [08:07] which involves quite complex combinations of events [08:08] and I've been increasingly wondering whether events are the right things to track, and whether we should instead deal with states [08:08] e.g. rather than "initctl emit tty-added tty1", you'd "initctl set tty-exists tty1 true" or something [08:08] (since then jobs would become just lists of and/or around states) [08:09] but after some thought, I've decided against that [08:10] because we are really receiving events, and trying to fob off turning them into states to the emitter is a bit crap [08:10] right [08:11] so having decided that upstart should still receive events [08:11] that means upstart has to deal with turning events into states [08:12] and so far I've been trying to define these states through Job [08:12] this, I think, is wrong [08:13] instead I think we should make State a first class [08:13] and have a way to describe a State, with reference to one or more Events [08:14] which means Job would just make reference to a State in which it was running [08:15] then instance jobs could optionally just have two State *, one for when instances exist, and the other for when those instances are running [08:15] e.g. the getty job [08:16] instances exist for each state tty-added ... tty-removed for a unique $TTY [08:16] and those instances are *running* for the "user can login" state (defined elsewhere) [08:17] this makes Job rather simpler [08:20] sounds good [08:20] in fact, I'm considering splitting Job up a bit more, so that the dealing with instances and replacement jobs is at a higher level clas [08:20] at the very least, we'd have Job -> State -> Event [08:21] and we have a good grip above on how to define State [08:21] Sounds good indeed. [08:21] it's a combination of periods of events [08:22] each item has an Event to be matched, and a pointer to the the EventEmission that matched it [08:23] events on the right-side of the period should be able to reference the emission in the left-side [08:23] e.g. tty-added tty[1-6] -> tty-removed $TTY [08:24] this therefore implies that the state has a value at any given time [08:26] which is the environment of any left side not cancelled out by a right side [08:28] so we can pass that on to the job [08:36] once the rhs is filled, we can discard the emission on the left since that needs to happen again [08:37] so we actually just need three pointers, start_event, stop_event and emission [08:37] and not bother retaining the emission for the stop event, since that just cancels the start one [08:38] we then just need boolean things [08:38] AND, OR, NOT for those structures [08:38] and AND and OR for the start/stop event trees [08:39] Fever ftw. [08:44] the thing causing me difficulty is [08:44] - telling a job which events happened in the tree [08:44] - positional arguments [08:47] any thoughts? [08:48] nope, sorry. my brain isn't working too good today [08:48] i'll have a think about it though [08:49] the only thing I could come up with was [08:49] - walk the tree in-order [08:50] - for each open state, push the event name into the list, and its positional arguments [08:50] - then pop the first event name, place in UPSTART_EVENT [08:50] so UPSTART_EVENT is the first event at the top of the tree [08:50] $1..$n are the arguments to that event [08:50] followed by "--" followed by the name of the next event, and that ones positional arguments [08:52] quite programming intensive [08:52] but I suspect it won't be a problem, since the only things caring will probably be tasks or state-based instances [08:52] and those will have only one or two events in their list [08:54] so for most people, $UPSTART_EVENT and $1...$n will be sufficient [08:54] e.g. [08:54] block-device-added ... block-device-removed $1 or partition-added ... partition-removed $1 [09:02] sounds ok? [09:03] yes === Md [i=md@freenode/staff/md] has joined #upstart [09:18] we'd probably end up needing separate files to define states in [09:18] maybe just /etc/upstart.conf or something [09:18] and obviously name them [09:20] and since jobs are now tied to states, not events, we'll have to rename /etc/event.d :p [09:22] rename it? shit. :p oh well, i suppose i can rebuild my entire upstart repo... ;) [09:22] lol [09:22] it's always been a temporary name === Keybuk has never liked it [09:23] how about 'upstart.d' ? :) [09:23] jobs.d? [09:23] I'd been trying to avoid using "upstart"'s name in its config files [09:23] it may be inevitable though [09:23] I wanted /etc/init.d ... but someone already used that [09:23] i would say init.d [09:23] heh [09:24] but it's used already ;) [09:25] likewise /etc/rc.d [09:25] (but then rc.d is kinda old) [09:25] frugalware still uses rc.d for it's sysv stuff (but we were originally based on slackware, so... ;)) [09:29] hmm :) there's a response from Mike Saunders (an LXF writer) on that post you made @ your blog [09:29] yeah I saw [09:30] I disagree with him [09:30] I think that the point of printed magazines is to have a single line of opinion [09:30] an editorial direction [09:30] me too [09:30] otherwise what do they give us that the online press doesn't? [09:30] right [09:30] there's one thing that's been annoying me with LXF recently [09:31] what's that? [09:31] they've been reviewing beta releases as the final product, and only mentioning in small print that it's the beta [09:39] their time-to-print seems extraordinarily long [09:39] I've noticed that before with them [09:39] their NEWS is amazingly out of date [09:40] yeah [09:42] could have /etc/service.d /etc/task.d and /etc/state.d [09:42] bit overkill though [09:42] yeah [09:43] why is it always ".d" anyway? [09:43] i prefer a central location rather than files dotted in a few directories over the place [09:43] dunno, i've always wondered that [09:44] difficult to google for ;) [09:46] it seems to have stemmed from when a file was turned into a directory [09:46] /etc/rc -> /etc/rc.d [09:46] probably the .d stands for directory [09:47] and it vaguely implies that if you concatenated all the files together, it's equivalent to just having a single file [09:47] which means that the /etc/event.d use would be "invalid" [09:47] since the name matters [09:47] but then the same is true for /etc/pam.d [09:48] and dbus' system.d [09:48] we do need to separate out jobs and states though [09:49] maybe [09:50] btw, will the replacement-initscripts spec *definitely* get implemented for gutsy? [09:51] no [09:51] it's strongly possible though [09:51] the only thing standing in the way is this complex event config problem [09:52] well, if you need any help with that just ask, i'll try to help with decisions if i can [09:54] see above ;) [09:54] :)