A Kernel Configuration Tale of Woe
Quoted 7 lines · Dimitrie O. Paun
Quoted 5 lines · Rusty Lynch
Quoted 4 lines
So how would you deal with somebody contributing bogus mappings? What if somebody was just wrong, or uploading a mapping in error?
Quoted 7 lines
Quoted 5 lines
The same applies to the kernel code, or any other open source project: How do you deal with somebody contributing bogus code?
Somehow things work out, as we have already witnessed.
For boards its not that simple. Many vendors release multiple > utterly different
machines with the same box, bios and ident.
Quoted 2 lines
The customer is told "IDE CD, 100mbit ethernet", the customer gets random cheapest going ethernet.
Agreed - so then the association between "board" and "chipset" must be capable of being multi-valued, and when there is a mult-valued match there must be some means of further interrogating the user (or user agent) for more information.
DG
Quoted 3 lines · Dennis Grant
Agreed - so then the association between "board" and "chipset" must be capable of being multi-valued, and when there is a mult-valued match there must be some means of further interrogating the user (or user agent) for more information.
Much simpler to just include "modular everything" and let user space sort it out. Guess why every vendor takes this path
Quoted 9 lines
Quoted 4 lines
For boards its not that simple. Many vendors release multiple > utterly different machines with the same box, bios and ident. The customer is told "IDE CD, 100mbit ethernet", the customer gets random cheapest going ethernet.
Agreed - so then the association between "board" and "chipset" must be capable of being multi-valued, and when there is a mult-valued match there must be some means of further interrogating the user (or user agent) for more information.
This demonstrates a very important point - _any_ automatic configuration program is likely to cause more traffic to this mailing list, and create more work for users and developers that the current automatic configuration process:
echo 'My box doesn't boot' | mail [email protected]
The kernel knows nothing about motherboards, cards, etc. It knows about chipsets, and nothing else. By definition, you cannot have a kernel configurator that works at a higher level than that.
Why don't we introduce a make allworkingmodules config, which compiles everything as modules, except for the things that are broken as modules, (for example IDE in the current 2.5.x tree would be compiled in).
John.
Quoted 7 lines · Alan Cox
Quoted 3 lines · Dennis Grant
Agreed - so then the association between "board" and "chipset" must be capable of being multi-valued, and when there is a mult-valued match there must be some means of further interrogating the user (or user agent) for more information.
Much simpler to just include "modular everything" and let user space sort it out. Guess why every vendor takes this path
Is there a tool though to map bus (PCI,USB etc) id's back onto modules which are likely[1] contain driver for them.
Given that many driver contain the Ids of the devices they will handle within their source, if this tool doesn't exist it could be built by ask modules to define a test_id function used both by themselves in the normal (ie , called in place of the code it moves into a seperate fucntion) way and compiled into a user space utility from the same kernel source.
TTFN
[1] Only likely, having met the nasty case of different
hardware with the same PCMCIA id, and PCI hardware which has a range of Ids associated with it.
Signature · 3 lines
Roger. Master of Peng Shui. (Ancient oriental art of Penguin Arranging) GPG Key FPR: CFF1 F383 F854 4E6A 918D 5CFF A90D E73B 88DE 0B3E
Quoted 11 lines · Roger Gammans
Quoted 7 lines · Alan Cox
Quoted 3 lines · Dennis Grant
Agreed - so then the association between "board" and "chipset" must be capable of being multi-valued, and when there is a mult-valued match there must be some means of further interrogating the user (or user agent) for more information.
Much simpler to just include "modular everything" and let user space sort it out. Guess why every vendor takes this path
Is there a tool though to map bus (PCI,USB etc) id's back onto modules which are likely[1] contain driver for them.
That's exactly what the hotplug package does.
See http://linux-hotplug.sf.net/ for more info. Odds are it's already installed on your box :)
greg k-h
Quoted 4 lines · John Bradford
Why don't we introduce a make allworkingmodules config, which compiles everything as modules, except for the things that are broken as modules, (for example IDE in the current 2.5.x tree would be compiled in).
cat > .force_default <<EOFCONFIG_BLK_DEV_IDE=yCONFIG_BLK_DEV_IDEDISK=y
EOF
make allmodconfig
That used to work, until 2.5.48. Being able to force selected options and have the rest of the options default to all Y or all M was extremely useful. What a pity that Kconfig removed this facility.
Hi,
Quoted 9 lines · Keith Owens
cat > .force_default <<EOF
CONFIG_BLK_DEV_IDE=yCONFIG_BLK_DEV_IDEDISK=y
EOF
make allmodconfigThat used to work, until 2.5.48. Being able to force selected options and have the rest of the options default to all Y or all M was extremely useful. What a pity that
Kconfigremoved this facility.
It's not that difficult to reimplement, but it was an undocumented feature, so I'd rather concentrated on the rest and waited until one of a few people who knew about this feature would complain.
bye, Roman
Quoted 8 lines · Roman Zippel
Quoted 6 lines · Keith Owens
cat > .force_default <<EOF
CONFIG_BLK_DEV_IDE=yCONFIG_BLK_DEV_IDEDISK=y
EOF
make allmodconfig
Quoted 6 lines
Quoted 3 lines
That used to work, until 2.5.48. Being able to force selected options and have the rest of the options default to all Y or all M was extremely useful. What a pity that
Kconfigremoved this facility.It's not that difficult to reimplement, but it was an undocumented feature
Bullshit. It was fully documented in kbuild 2.5. Just because Kai dropped the docs when he stole bits from kbuild 2.5 does not make .force_default into an undocumented feature.
Quoted 2 lines
so I'd rather concentrated on the rest and waited until one of a few people who knew about this feature would complain.
People do not know about it because Kai dropped the docs.
Quoted 3 lines · Keith Owens
Bullshit. It was fully documented in kbuild 2.5. Just because Kai dropped the docs when he stole bits from kbuild 2.5 does not make .force_default into an undocumented feature.
I never seen this as a standalone patch from you - something i missed?
I do not remember exactly but I may have been the person extracting this from kbuild-2.5 and feeding this patch to Kai, in which case you should blaim me, not Kai.
If you were not properly attributed at that point in time, sorry for that.
If kconfig are extended with functionality similar to .force_default then the file containing the defaults shall NOT be hidden. There is no good reason to hide for the user that some options are forced to a specific value.
IIRC the old implementation only impacted "make oldconfig", so doing something like:
echo CONFIG_HOTPLUG=y > .force_default
make oldconfig
make menuconfig, enable HOTPLUG
Manually tweak .config and run make oldconfig
then I would behind my back loose the hotplug setting, without any warning.
If implemented defaults should be effective in all frontends, not only make oldconfig. Forced defaults should be unchangable in the frontends. It is not intuitive for the user that at one point something is forced enabled, and then later the user are anyway allowed to change it without further notice.
Sam
Quoted 3 lines · Keith Owens
Bullshit. It was fully documented in kbuild 2.5. Just because Kai dropped the docs when he stole bits from kbuild 2.5 does not make .force_default into an undocumented feature.
$ bk changes -r1.403.20.3 [email protected], 2002-06-05 19:40:54-05:00, [email protected] kbuild: Additional config targets for testing
This patch adds the following targets, which generate some configs useful for testing - which kind should be clear from the names:
o allyesconfig
o allmodconfig
o allnoconfig
o randconfig
It also adds
o defconfig
which does the same as make oldconfig but uses the defaults for all new options without asking.
The actual patch was done by Ghozlane Toumi, maintained in kbuild-2.5 by Keith Owens, and extracted by Sam Ravnborg and [email protected].
Don't you think accusing me of "stealing" from kbuild-2.5 is a bit harsh???
--Kai