EISA in GENERIC

Matthew Rezny matthew at reztek.cz
Wed Apr 16 17:15:56 UTC 2014


On Wednesday 16 April 2014 10:56:42 you wrote:
> On Apr 16, 2014, at 10:36 AM, Matthew Rezny <matthew at reztek.cz> wrote:
> >> Warner Losh <imp at bsdimp.com> writes:
> >>> The time has come to trim EISA from the generic i386 kernel.
> >> 
> >> Can we also remove ISA network adapters?
> >> 
> >> DES
> >> --
> >> Dag-Erling Smørgrav - des at des.no
> > 
> > Remove from GENERIC? Go ahead.
> > Remove from src tree? No.
> > 
> > I see no reason to need ISA NICs or storage support in GENERIC on amd64
> > and
> > little reason have it in GENERIC for i386. General ISA support needs to
> > remain for sio/uart and lpt. Anyone using ISA network, storage, sound,
> > etc is probably ok building a custom kernel.
> > 
> > My fist thought when I saw this thread was "I hope someone doesn't ask to
> > remove ISA support".
> 
> ISA support simply cannot be removed from the tree, full stop. It is our
> generic bus on x86, and many things that don’t have a better attachment are
> attached here. While some movement towards ACPI has happened here, we
> haven’t done a good job of cutting the cord here because things work well
> enough for people to focus on other things.
> 
> Most, but not all, ISA network, storage and sound drivers have loadable
> modules, so could easily be loaded at boot should someone wish to run
> GENERIC and still have these devices supported. So there’s a back-door to
> getting a system recovered from modern boot media (assuming, of course,
> that these systems could boot off modern boot media).
> 
> In addition, many of the ISA drivers are also PC Card drivers. I still get
> many questions about PC Card devices and drivers. At least with PC Card,
> though, we could automatically load the right .ko 95% of the time. But this
> gets us back to the no generic bus-level matching code infrastructure that
> could be mined to get this data. USB does this with a set of scripts that
> are kludgy in the sense they are only for USB. PCI could do it, but some
> drivers would need a lot of work. USB, PC Card and ISA PNP could do it,
> with some special marking of the arrays. Old-school ISA, where we have
> to have identify routines or hints can never be automatically loaded in
> response to plug and play data from the bus (but perhaps could be loaded
> based on the presence of hints).
> 
> So it is for all these reasons I don’t want to talk about ISA at this time.
> It is a much messier situation, with ugly tendrils into weird places. EISA,
> on the other hand, is very well contained and very easy to turn on/off once
> the right build knobs are in place (since it already was close to being
> trivial to get rid of).
> 
> Warner

I guess I was a little unclear. What I meant was I think it is fine if we we 
remove all ISA network and storage drivers from GENERIC, so long as they 
remain in tree so they can be loaded as modules or compiled into custom 
kernels.

I'm well aware that ISA provides essential functionality on i386, so we can't 
get rid of ISA bus support. I consider that topic off the table. I perhaps 
caused confusion in the last sentence. What I meant there was "I hope someone 
doesn't ask to remove all ISA device support from GENERIC", as in the serial 
ports and floppy controller specifically.



More information about the freebsd-arch mailing list