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