On Tue, 10 Mar 2015 17:56:59 +0000 Isaac Dunham <[email protected]> wrote:
> On Tue, Mar 10, 2015 at 01:37:41PM +0100, Harald Becker wrote: > > Hi Laurent ! > > >... I dislike the idea of integrating early init functions into mdev, > > >because those > > >functions are geographically (as in the place where they're performed) > > >close to mdev, > > > but they have nothing to do with mdev logically. > > > > Sorry, I don't agree. mdev's purpose is to setup the device file system > > infrastructure, or at least to help with setting up this. Ok, at first leave > > out proc and sysfs, there you may be right, but what about devpts on > > /dev/pts, or /dev/mqueue, etc., and finally the tmpfs for /dev itself. Do > > you really say they do not belong to the device file system infrastructure? > > Or all those symlinks like /dev/fd, /dev/stdin, /dev/stdout, etc., do you > > consider them not to belong to mdev? Not talking about setting owner > > informations and permissions for those entries in the device file system. > > > > In my humble opinion, these do not belong to mdev the busybox applet. +1 ... > Factors that make me want this: > * mdev can noticeably slow down boot (I've set up mdev as hotplug helper > with Debian, and notice that the resulting initrd takes a second or two > more than udev to load.) I would assume that loading all the modules > in Debian results in a fork bomb. This is why I want a separate pipe for modaliases. I want disable MODALIAS handling from mdev and add modprobe -i support with a timeout feature. > * hotplug is a rare event, but with modern hardware it frequently causes > a sudden burst of activity. > A flash drive frequently triggers 5+ events, and plugging in a phone/ > turning on mass storage may cause a dozen or more. > Even plugging in an SD card may cause 3 or more events. Exactly. The events comes in bursts. That is why i think it makes sense to auto spawn the handler, forward the event via a pipe and exit the handler on periods with no activity. > The long lived instance probably needs to stay out of busybox to make > this really minimize memory use, though. +1 > Certainly it shouldn't be in the same binary as mdev. (Some people > use multiple busybox binaries, which is probably more optimal.) Agree. ... > Now, a comment or two on design of mdev -i and the netlink listener: > I really *would* like there to be a timeout of some sort; in my > experience, 1 second may be rather short, and 5 seconds is usually > ample. > I also think that the timeout should be adjustable. > Now, the timeout could be done in at least two ways: > (a) timeout in mdev -i: > disable timeout on read (or set timeout for executing rules) > parse input and execute rules > at the end of execution, reset timeout for read > (b) timeout in netlink daemon: > listen for events > on event: > disable timeout > check state of mdev/pipe > respawn if needed > write event to pipe > check write result; if needed, retry > reset timeout > on timeout: > close pipe and let mdev die when it finishes > > Everything but the timeout has to be done anyhow in both mdev and the > netlink daemon. > > In (a), the timeout could be set on the mdev commandline, or in mdev.conf; > if it is set on the mdev commandline, *that* needs to be specified on > the netlink daemon's commandline or in its config file. if you set it on the command line then you need respawn the netlink listener if you want change it. (or having the netlink listener re-read a config file on every event. i dont think we want that) If we use mdev.conf you can just change that file and kill mdev and new setting is active. Not that this is a big issue. Just interesting consequence which i had not thought of. > In (b), the timeout is specified in the netlink daemon's commandline or > in its config file. > > Somehow, I find myself prefering option (b); managing timeouts seems to > be the job of a daemon rather than a hotplugger, and it fits logically > with everything else that the netlink daemon is doing. I tend to prefer option (a) because the netlink daemon needs to deal with a killed mdev anyway. If we let mdev handle the timeout then the netlink daemon only need to check for POLLHUP on the pipefd. This also has the befit that the long lived daemon becomes smaller. -nc _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
