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