Re: Parent "device" selection in kernel configuration

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi,

> OK.  So the driver doesn't change -- nor the features available
> to the "device", itself.  E.g., it doesn't *add* (or remove)
> any capabilities that aren't always present, regardless.

That's correct.  The driver is often split up into the code to handle the
chip itself (src/sys/dev/ic/*) and the frontends which handle the bus
attachments (src/sys/dev/isa/*, src/sys/dev/pci/*), etc.  Also, for example,
some IC's are only available as PCI, so the driver code and the attachment
code are in a single file.

> (consider something like a network interface... would *how*
> it is attached affect whether or not "wake on LAN" was
> supported?)

This is more likely to be something that is supported or not based on
the particular chipset.  I'm not sure quite where "wake on LAN" would
fit, as this is something external to the standard functioning of the
network chip.  Perhaps a better example would be a driver for a family
of chips, where only some support TCP/UDP checksum offload.  The bus
attachment wouldn't alter this ...

> If, for example, there were extra levels of indirection in the
> ISR's one way or another.  Or, some forced sharing of resources
> in one approach that were not present in others...

... as the bus attachments handle the indirection for interrupts, memory
or I/O mapping, etc.  For example, looking at the AMD 7990 ethernet driver,
the common driver code is in src/sys/dev/ic/am7990.c, and the bus-specific
parts are in (for example):

  ISA     src/sys/dev/isa/if_le_isa.c
  ISAPnP  sys/dev/isapnp/if_le_isapnp.c
  SBUS    src/sys/dev/sbus/if_le.c

If you look at the attachment routines for the above, you can see that they
set up the bus-specific parts, and they all call am7990_config() for the
common attachment.  This means that a kernel can support that IC, but only
some attachments for it, by only including some "le at *" lines.

> I'm trying to trim down the kernel for deployment on a cluster of
> 1GHz/1GB *diskless* machines.  So, anything I can purge from the memory
> footprint is space that I can use for something else.  Code that is
> effectively *dead* doesn't buy me anything at runtime.  And, if one
> approach tied up extra data structures that weren't necessary with
> a different approach...

A simple thing to do is remove support for all the bus-types (and devices
for that bus) that aren't present.  Then, you could remove all the devices
that aren't or won't be present.  After that, you might want to remove some
parts of the kernel that you don't want.  For example, you could decide to
remove RAIDframe, or IPSEC, or FFS.  With a 1GHz/1GB machine, I'm not sure
that this will make that much difference though.

Thanks,

J

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/