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