A Kernel Configuration Tale of Woe
Quoted 2 lines
I think he missed the solution rather than missing the problem
I think I may agree with you, to a point, in that (after further reflection) I think there's an intermediate step between the current state and the magical world of "make partsconfig" or even "make autoconfig"
The real problem is the difficulty in mapping a given hardware configuration to a kernel version and a subsequent kernel configuration. There's no smooth road to get from one to the other. Paving that road solves the problem; the only question is of degree. The "make autoconfig" case is the ideal, but we don't necessarily need the ideal. Perfect is the enemy of good enough.
I started doing a little doodling, and I came up with a very rough sort of relationship map. I don't present this as the ideal data model - it's a start point at best.
A "box" is composed of "devices" and "subcomponents"
A "subcomponent" is composed of "chipsets"
A "chipset" provides a set of "capabilities"
A "device" requires a set of "capabilities"
A "chipset->capability::capablility<-device" pair defines an "interface" An "interface" has associated with it:
a) the kernel version where it first became availible
b) the kernel config switches that activate it
So what is needed is some way to start at the "box" level, and given the set of subcomponents and devices associated with it, spit out a list of a) and b)
Here's the mini-eureka I've had - that need not actually be a part of the kernel config system, although the kernel config system might potentially make use of it.
What would suffice would be some sort of online database, published in a highly visible location, and crosslinked from hell and back to make it likely to be discovered in a Google-driven troubleshooting session. Provide motherboard make and model (a subcomponent) any expansion cards (also subcomponents) and the make and model numbers of drives et al (devices) and then query the database and present the report.
I'm envisioning something very much like the CDDB service. This is a little more complex, but the concept is similar. And like the CDDB service, it could be queried over the network by some future "make" option if somebody decided to implement that.
Also like the CDDB service, it makes use of network effects. No one person has to populate the _entire_ database. The association of "subcomponents" to "chipsets" (or "devices" to "capabilities") might be done by the manufacturer, or it might be done by the developer who actually debugged the original driver instance, or it might even be done by someone like myself (a sufficiently clued-in sysadmin who did it the hard way and wants to help those who will follow after him)
All that matters is that _somebody_ contribute one little portion of the mapping, and then, given enough somebodies, the entire map assembles itself.
And if Microsoft hasn't dared attempt such a thing... well, then that would make it an "innovation", wouldn't it? ;)
DG
Quoted 1 line
I started doing a little doodling, and I came up with a very rough sort of
relationship
Quoted 1 line
map. I don't present this as the ideal data model - it's a start point at
best.
Quoted 11 lines
A "box" is composed of "devices" and "subcomponents"
A "subcomponent" is composed of "chipsets"
A "chipset" provides a set of "capabilities"
A "device" requires a set of "capabilities"
A "chipset->capability::capablility<-device" pair defines an "interface" An "interface" has associated with it:
a) the kernel version where it first became availible
b) the kernel config switches that activate it
Quoted 1 line
So what is needed is some way to start at the "box" level, and given the
set
Quoted 1 line
of subcomponents and devices associated with it, spit out a list of a) and
b)
Quoted 3 lines
Here's the mini-eureka I've had - that need not actually be a part of the
kernel
Quoted 1 line
config system, although the kernel config system might potentially make
use
Quoted 3 lines
of it.
What would suffice would be some sort of online database, published in a
highly
Quoted 1 line
visible location, and crosslinked from hell and back to make it likely to
be
Quoted 1 line
discovered in a Google-driven troubleshooting session. Provide motherboard
make
Quoted 1 line
and model (a subcomponent) any expansion cards (also subcomponents) and
the
Quoted 1 line
make and model numbers of drives et al (devices) and then query the
database
Quoted 3 lines
and present the report.
I'm envisioning something very much like the CDDB service. This is a
little
Quoted 1 line
more complex, but the concept is similar. And like the CDDB service, it
could
Quoted 1 line
be queried over the network by some future "make" option if somebody
decided
Quoted 3 lines
to implement that.
Also like the CDDB service, it makes use of network effects. No one person
has
Quoted 1 line
to populate the _entire_ database. The association of "subcomponents" to
"chipsets"
Quoted 1 line
(or "devices" to "capabilities") might be done by the manufacturer, or it
might
Quoted 1 line
be done by the developer who actually debugged the original driver
instance,
Quoted 1 line
or it might even be done by someone like myself (a sufficiently clued-in
sysadmin
Quoted 3 lines
who did it the hard way and wants to help those who will follow after him)
All that matters is that _somebody_ contribute one little portion of the
mapping,
Quoted 2 lines
and then, given enough somebodies, the entire map assembles itself.
So how would you deal with somebody contributing bogus mappings? What if somebody was just wrong, or uploading a mapping in error?
Quoted 1 line
And if Microsoft hasn't dared attempt such a thing... well, then that
would
Quoted 3 lines
make it an "innovation", wouldn't it? ;)
DG
Quoted 2 lines · Rusty Lynch
So how would you deal with somebody contributing bogus mappings? What if somebody was just wrong, or uploading a mapping in error?
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.
Signature · 1 line
Dimi.
[email protected] (Dennis Grant) wrote on 26.11.02 in <[email protected]>:
Quoted 6 lines
Quoted 2 lines
I think he missed the solution rather than missing the problem
I think I may agree with you, to a point, in that (after further reflection) I think there's an intermediate step between the current state and the magical world of "make partsconfig" or even "make autoconfig"
Well ... it seems to me that the main difference is that (a significant part of) "make autoconfig" *actually exists*.
MfG Kai
Quoted 8 lines · Dimitrie O. Paun
Quoted 2 lines · Rusty Lynch
So how would you deal with somebody contributing bogus mappings? What if somebody was just wrong, or uploading a mapping in error?
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. The customer is told "IDE CD, 100mbit ethernet", the customer gets random cheapest going ethernet.
Alan
Quoted 53 lines · Dennis Grant
Quoted 2 lines
I think he missed the solution rather than missing the problem
I think I may agree with you, to a point, in that (after further reflection) I think there's an intermediate step between the current state and the magical world of "make partsconfig" or even "make autoconfig"
The real problem is the difficulty in mapping a given hardware configuration to a kernel version and a subsequent kernel configuration. There's no smooth road to get from one to the other. Paving that road solves the problem; the only question is of degree. The "make autoconfig" case is the ideal, but we don't necessarily need the ideal. Perfect is the enemy of good enough.
I started doing a little doodling, and I came up with a very rough sort of relationship map. I don't present this as the ideal data model - it's a start point at best.
A "box" is composed of "devices" and "subcomponents"
A "subcomponent" is composed of "chipsets"
A "chipset" provides a set of "capabilities"
A "device" requires a set of "capabilities"
A "chipset->capability::capablility<-device" pair defines an "interface" An "interface" has associated with it:
a) the kernel version where it first became availible
b) the kernel config switches that activate itSo what is needed is some way to start at the "box" level, and given the set of subcomponents and devices associated with it, spit out a list of a) and b)
Here's the mini-eureka I've had - that need not actually be a part of the kernel config system, although the kernel config system might potentially make use of it.
What would suffice would be some sort of online database, published in a highly visible location, and crosslinked from hell and back to make it likely to be discovered in a Google-driven troubleshooting session. Provide motherboard make and model (a subcomponent) any expansion cards (also subcomponents) and the make and model numbers of drives et al (devices) and then query the database and present the report.
I'm envisioning something very much like the CDDB service. This is a little more complex, but the concept is similar. And like the CDDB service, it could be queried over the network by some future "make" option if somebody decided to implement that.
Also like the CDDB service, it makes use of network effects. No one person has to populate the _entire_ database. The association of "subcomponents" to "chipsets" (or "devices" to "capabilities") might be done by the manufacturer, or it might be done by the developer who actually debugged the original driver instance, or it might even be done by someone like myself (a sufficiently clued-in sysadmin who did it the hard way and wants to help those who will follow after him)
Quoted 7 lines
All that matters is that _somebody_ contribute one little portion of the mapping, and then, given enough somebodies, the entire map assembles itself.
And if Microsoft hasn't dared attempt such a thing... well, then that would make it an "innovation", wouldn't it? ;)
DG
I thought Alan responded quite well, but now you have a "solution" to a problem that doesn't exist. Really.
To make myself perfectly clear, Unix and Unix clones come to life running one program called init. It reads some scripts that tells it how to configure the machine the way an end-user wants it. Look in /etc/rc.d. There are various scripts or links to scripts for various 'run-levels'.
If you don't know this or understand this, then I can't help you. To 'auto-configure', all you need is a kernel that is configured for modules. As Alan pointed out, it's also helpful to have a kernel that boots an initial RAM-Disk so that a driver to run your root- file-system hard disk can be loaded.
All you need to do, to auto-configure, under these conditions is to run shell-scripts or any kind of programs you want upon boot. This scripts or programs can probe, query, cajole, or do anything else you want, to find out what hardware you have, whether you want to load a driver (module) and if you want to enable it. This can all be done automatically upon boot. It doesn't require any special kernel capabilities other than what already exists.
The auto-configure really, truly, doesn't have anything to do with the kernel. If your distribution doesn't do what you want, you can make it do what you want if you are capable, or you can contact the distributor with your suggestions.
The 'auto-configuration' of the kernel proper, to load various drivers is typically done to 'optimize' a particular system. For this optimization, one would build-in the drivers so that modules don't have to be loaded. One would also enable specific code enhancements for specific processors. To do this, you really need to tell some script or program what you are intending to do. Currently, we have two ways of doing this. There is a graphical kernel configuration and a text-mode kernel configuration. These user configuration methods really have to believe what the user tells it to do.
That said, you can write a program that looks at a properly functioning system, and from what it sees, it could create a '.config' file that could be used as input for make old_config. This could cut down the amount of time necessary to optimize the kernel for a specific system. But, then again, that program, although it makes a kernel- configuration file, is not really a kernel issue.
Since I loaded my first distribution from, I think it was 57 floppy disks, to the current ones, I have hoped that somebody would make a kernel autoconfiguration utility but so far it hasn't been done, probably because the kernel is usually configured to boot some other machine. In that case, the existing manual configuration needs to believe what the user says.
I'm going to bow out of this discussion before I get whacked for not being on-topic myself. Contact me off the list for further discussion. If somebody wants some help in setting up some boot-time autoconfiguration that they don't already have, you can contact me off-list, also.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America