On 05/04/12 01:58, David Weinehall wrote: > On Thu, May 03, 2012 at 08:54:11AM +0800, Patrick Lauer wrote: >> On 05/03/12 02:16, Michael Biebl wrote: >>> On 02.05.2012 19:05, Martin Wuertele wrote: >>>> I don't think this is a better example. Actually I think this is an >>>> example where udev/mdev could launch/stop bluetoothd. >>> Long running daemons should *not* be started by udev. udev is *not* a >>> service manager. >>> What udev should do is signal the init system that the device is >>> available and the init system will start and manage the daemon. That's >>> what systemd and upstart do. >>> >> So, this whole sub-thread boils down to this: >> >> "Our current init scripts don't handle dependencies properly" >> >> Once you fix that you can just let udev trigger /etc/init.d/bluetooth >> start, and that will do all the needed magic properly. >> >> ... and OpenRC has been doing that for such a long time that I find it >> hard to understand that people are still not using it ;) >> >> I'm still slightly confused what people mean with "event based", I think >> there are at least three similar, but distinct definitions going around. >> A good part of that is already handled by the device manager, and the >> rest appears to be user actions - if someone can find me a good example >> of an event that doesn't fit into these categories I might understand >> why from my point of view people seem to be violently agreeing so hard. > So, what you're saying is that we should fork udev to do things that > neither its upstream developer nor its Debian maintainer doesn't intend > for it to do, Not at all. I'm possibly suggesting actually using udev features, but then I guess upstream will remove all of them that are fun > all to make it possible to use an init-system that doesn't > support events, instead of using an event based system that's designed > to work with udev? Somehow I get the feeling that I've asked this before, in which case I'd be repeating myself, which is very rude of you ... but ... *which* events !? If it's only device hotplugging / uevents we already have a handler for that that can execute arbitrary code (udev/mdev), if not then someone should at some point in time enlighten me what "event based" means to them so I can finally see why people are disagreeing there. 'cause right now it looks like violent agreement to me, which makes little sense :)
> > Yeah, makes perfect sense... > Sense ... if we had some more of that this discussion wouldn't have started at all ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa323ea.4000...@gentoo.org