Good evening, Kenneth,
On Wed, 7 Jun 2000, Kenneth C. Arnold wrote:
> On Wed, Jun 07, 2000 at 11:26:49AM -0400, William Stearns wrote:
> > I'd like to start in identifying what busses a particular kernel
> > option might show up under - i.e. EEPRO100 could be PCI, but never ISA,
> > MCA, USB, SBUS, etc., NE2000 could be ISA, PCI... This would allow the
> > kernel configuration process to completely avoid any devices that could
> > not possibly be connected to this machine.
>
> This can't be too restrictive, or we get into messes when a vendor releases
> a new product on a different bus based on the same chipset. Putting it in
> the config dependancies is probably ok, but try not to depend on the bus in
> the driver as much as possible just because it is only available for that bus.
Excellent point; a given chipset might later show up in a
different bus. The NE2000 alone illustrates that point; do we have I20
ne2k's yet? *smile*
Unfortunately, I suspect I'll have to use the bus type specified
in the source until the chipset shows up on a new bus. As new chips some
out, we'll update the dependancies.
> On the other hand, it looks like Eric has already put some of this stuff
> into CML2. Check out the following lines, for example:
>
> unless MCA suppress ELMC ELMC_II ULTRAMCA SKMC NE2_MCA
> unless ISA suppress NET_ISA eth_isa_drivers ISA3C515
> unless PCI suppress NET_PCI eth_pci_drivers
> unless PCI suppress dependent TULIP EEPRO100 NE2K_PCI
>
> Maybe expand these to include all the possibilities?
Actually, CML2 is where this process partly began. Jeff Dike
(User Mode Linux Guru) and I wanted to get the main configuration tree to
the point where it can disable all physical hardware if a User-Mode Linux
kernel is being created (as UML doesn't talk to any hardware). Eric
Raymond pointed out that this could be very gracefully handled in CML2
with exactly the above types of lines. The addition of something like
if UML suppress PCI ISA MCA SBUS...
would, IMHO, quite gracefully allow the kernel to support one
configuration tree for standard and uml kernels instead of having to
maintain a separate treee for uml. The even more elegant side effect is
that users of the standard kernel configuration only see the devices their
system could possibly support (modulo your previous concern about chips
showing up on different busses).
The same research could be applied to the existing Config.in's as
well - it's just a matter of pulling the information together.
"Just", he says. I'm realizing how big a project this is and how
much research will be necessary.
Cheers,
- Bill
---------------------------------------------------------------------------
"So, who do you work for? Micro or Soft?"
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com). Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:16 EST