Re: RFC: OpenRC as Init System for Debian
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 ;)
Reply to: