* Carlos Alberto Lopez Perez <clo...@igalia.com> [2012-05-01 23:07]: > On 27/04/12 19:33, Tollef Fog Heen wrote: > > ]] Martin Wuertele > > > >> * Josselin Mouette <j...@debian.org> [2012-04-27 09:53]: > >> > >>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : > >>>>> Yes of course, because event-driven init systems have *always* been > >>>>> *only* about mounting USB devices. > >>>> > >>>> Then explain the _real_ reasons for having an event driven boot system! > >>> > >>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN. > >> > >> That's a reason for udev/mdev, however I still fail to see why this > >> results in the requirement for an event based boot process. > > > > A trivial example is $remote_fs isn't satisfied until /srv/somewhere is > > mounted and /srv/somewhere comes off iscsi, which means it requires > > networking to be up, which means network drivers loaded, etc. So the > > event «network driver loaded» causes ifup to be spawned, which causes > > $network to be satisfied which causes the iscsi daemons to be started > > which causes mount to be called. > > > > A better example is bluetooth. > > In my Debian system I have /usr/sbin/bluetoothd running and I don't have > any bluetooth devices on my system... So wouldn't be better that instead > of launching the bluetooth daemon and let it waiting for the day that I > plug a USB bluetooth device (and still I never did that) to just launch > this daemon only when the kernel detects a bluetooth device?
I don't think this is a better example. Actually I think this is an example where udev/mdev could launch/stop bluetoothd. Yours Martin -- 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/20120502170533.ga11...@anguilla.debian.or.at
