1 |
On Sun, Mar 24, 2019 at 3:46 AM Peter Humphrey <peter@××××××××××××.uk> wrote: |
2 |
> |
3 |
> On Sunday, 24 March 2019 01:03:23 GMT Walter Dnes wrote: |
4 |
> > When setting up a new kernel with "make oldconfig", almost all new |
5 |
> > device drivers default to "N". The glaring exception is network cards. |
6 |
> > They all seem to default to "Y". Is this a bug or a "feature"? |
7 |
> |
8 |
> It seems to be just to reveal the individual cards by that manufacturer. I |
9 |
> don't see why it should differ from any other hardware options. Perhaps it's a |
10 |
> leftover from a day long ago that no-one's thought to change. |
11 |
> |
12 |
|
13 |
I suspect it is because these options basically work opposite normal |
14 |
ones. They're phased as "Do you want to see Acme network cards?" with |
15 |
a default of Yes. However, they way they effectively work is "Do you |
16 |
want to disable all Acme network cards?" with a default of No. |
17 |
|
18 |
Suppose you have an Acme model 1234 network card. You've previously |
19 |
answered Yes to enabling its driver, and No to enabling the Acme model |
20 |
2345 card. |
21 |
|
22 |
Now a new option comes along to show/hide all the Acme cards. That is |
23 |
a new option, so it has no existing value as far as the config |
24 |
database design goes. If you answer No, then you disable your model |
25 |
1234 card (without even being asked, because that isn't a new option). |
26 |
If you answer yes then effectively your previous choices remain in |
27 |
effect (model 1234 remains enabled, and model 2345 remains disabled). |
28 |
|
29 |
Now, obviously a more elegant solution would be to look at all the |
30 |
models of Acme cards in the database and see if you've selected any, |
31 |
and use that to set the default. However, that would require a change |
32 |
to how the entire config system works most likely. |
33 |
|
34 |
I might have a detail wrong and lkml is definitely where to go for the |
35 |
full answer, but I suspect this was the rationale behind this design |
36 |
decision. Those options effectively don't do anything but expose more |
37 |
options, so defaulting them to Yes probably made more sense, because |
38 |
defaulting to no would disable anything that depends on them. |
39 |
|
40 |
In any case, this is purely an upstream kernel issue, so you can |
41 |
always try to convince Linus that he has it wrong. :) |
42 |
|
43 |
-- |
44 |
Rich |