Am 17.10.2011 13:30, schrieb Neil Bothwick: > On Mon, 17 Oct 2011 12:19:16 +0100, Mick wrote: > >>> This seems more elegant than a separate init script, but do you want >>> it to return 0 unconditionally? If the modules fail to load, surely >>> you want the attempt to bring the interface up to abort? >> >> In my head I find it less elegant to be honest. Is it up to a network >> configuration script to load the *kernel* module for the hardware? > > Is it up to an init script to do that either? I'd say no. either way > seems wrong, but having the network config check that the interface is > available before trying to bring it up seems somewhat less wrong. > >
Yes, I intended it to return 0 unconditionally. My reasoning was that a) trying anyway doesn't hurt. b) when you change your kernel config or hardware and don't need that workaround anymore, it is better to have a working network and a warning rather than no network and an error. c) for something that is potentially important for the user to get access to the system, you should try as hard as possible to get it running before giving up. Of course, this is more important for a headless server than a desktop but scripts tend to get copied around. Concerning what is more elegant: no clue. I guess you could even use udev for this stuff but I don't know the syntax. One thing that I worry more about is that there might be a race condition. Maybe after loading the module, some time is necessary for the interface to appear. I ran into an issue like that while playing around with the zram module. In such a case, the separate init script has a higher chance to succeed than a bash function called some milliseconds before the interface initialization. Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
