| Keybuk | sadmac_: yes | 01:20 |
|---|---|---|
| Keybuk | though in 0.3.x it will probably contain the event that stopped the job | 01:21 |
| Keybuk | whereas in trunk, UPSTART_EVENTS will contain the events that originally started it | 01:21 |
| keesj | Hi | 12:08 |
| Keybuk | hi | 12:16 |
| keesj | The chance I wil use upstart are growing every day :p | 12:24 |
| keesj | I am now looking into the kernel->upstart communication | 12:25 |
| keesj | special I am looking at the udev from the replacement-initscripts http://paste-it.net/7162/raw/ | 12:28 |
| keesj | that script has a "emits block-device-added block-device-removed" section | 12:29 |
| keesj | what it that good for? | 12:32 |
| Keybuk | "emits" is just a documentation stanza | 12:32 |
| Keybuk | you'd use it in the job definitions of services that are known to emit their own events | 12:33 |
| Keybuk | and that way other frontend tools can draw pretty dependency graphs using things like dotty | 12:33 |
| keesj | sexy :p | 12:33 |
| Keybuk | it's not actually used by Upstart in any way, other than being available as a property | 12:33 |
| Keybuk | the theory there is that that distribution would ship udev rules that looked something like: | 12:34 |
| Keybuk | SUBSYSTEM=="block", ACTION=="add", RUN+="/sbin/initctl emit block-device-added DEVPATH" | 12:34 |
| Keybuk | SUBSYSTEM=="block", ACTION=="remove", RUN+="/sbin/initctl emit block-device-removed DEVPATH" | 12:34 |
| Keybuk | SUBSYSTEM=="net", ACTION=="add", RUN+="/sbin/initctl emit network-device-added INTERFACE" | 12:35 |
| Keybuk | SUBSYSTEM=="net", ACTION=="remove", RUN+="/sbin/initctl emit network-device-removed INTERFACE" | 12:35 |
| Keybuk | etc. | 12:35 |
| Keybuk | alternately we may want an upstart-addon-udev or something so we could have a generic RUN+="socket:/com/ubuntu/upstart/udev" at the end, and let the addon daemon turn those into events | 12:35 |
| Keybuk | OR we might just patch udev directly to emit events into upstart | 12:35 |
| keesj | my system does not use udev, i currently use <linux/netlink.h> to recieve NETLINK_KOBJECT_UEVENT events | 12:37 |
| keesj | I could just create a mini app that gets started and emits the kernel uevent | 12:38 |
| keesj | hmm I will look into it | 12:40 |
| Keybuk | right | 12:43 |
| Keybuk | you could have a little daemon to listen on the netlink socket and inject into upstart | 12:43 |
| keesj | I do have the same kind of problems that are solved by udev , being that if a device get plugged before the daemon is started I will never know about | 12:44 |
| keesj | I then have to write custom code to look at the status . | 12:45 |
| Keybuk | why not just write to the uevent files like udev does? | 12:56 |
| Keybuk | for each object under /sys that a uevent was originally emitted for, there will be a uevent file | 12:56 |
| Keybuk | write "add" (no \0, no \n, etc.) to that, and the kernel will resend it | 12:56 |
| keesj | Thanks for the tip , I will have to look into how that works! | 13:03 |
| Keybuk | ion_: interesting thought of the day | 19:12 |
| Keybuk | all of the dbus_bus_ calls block | 19:12 |
| ion_ | keybuk: Is that a problem? | 19:17 |
| Keybuk | I'm not sure | 19:18 |
| Keybuk | the fact that dbus_bus_get() can never return worries me enough :p | 19:20 |
| ion_ | Heh | 19:20 |
| Keybuk | I guess it depends at what level of blocking we have to worry about in Upstart | 19:23 |
| Keybuk | in some senses, blocking is actually not necessarily bad | 19:24 |
| Keybuk | since it reduces system load | 19:24 |
| Keybuk | e.g. upstart blocks while it sets up a process, even though that's happening the child | 19:24 |
| Keybuk | and doesn't move onto the next until exec() completes | 19:24 |
| Keybuk | so arguably, after starting dbus, blocking to connect to it and say Hello isn't too bad | 19:24 |
| ion_ | Yep... | 19:40 |
| ion_ | Don’t they have a separate DBus (client) implementation in C#? Perhaps someone should NIH a DBus implementation that doesn’t suck in C. ;-) | 19:56 |
| Keybuk | ndesk-dbus | 19:56 |
| Keybuk | the C API isn't really that bad | 20:01 |
| Keybuk | the main problem is just figuring out how to dispatch methods | 20:01 |
| keesj | ion_: that would be great | 20:14 |
| Amaranth | @btlogin | 21:17 |
| Amaranth | err | 21:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!