Date: Wed, 16 Apr 2014 19:15:44 +0200 From: Matthew Rezny <matthew@reztek.cz> To: freebsd-arch@freebsd.org Subject: Re: EISA in GENERIC Message-ID: <5384422.Lmm1UmY4VK@desktop.reztek> In-Reply-To: <421F815B-906C-4CD0-8D5B-349FBD5B6607@bsdimp.com> References: <7524617.WO5TPN2b6E@desktop.reztek> <421F815B-906C-4CD0-8D5B-349FBD5B6607@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 16 April 2014 10:56:42 you wrote: > On Apr 16, 2014, at 10:36 AM, Matthew Rezny <matthew@reztek.cz> wrote= : > >> Warner Losh <imp at bsdimp.com> writes: > >>> The time has come to trim EISA from the generic i386 kernel. > >>=20 > >> Can we also remove ISA network adapters? > >>=20 > >> DES > >> -- > >> Dag-Erling Sm=C3=B8rgrav - des at des.no > >=20 > > Remove from GENERIC? Go ahead. > > Remove from src tree? No. > >=20 > > I see no reason to need ISA NICs or storage support in GENERIC on a= md64 > > and > > little reason have it in GENERIC for i386. General ISA support need= s to > > remain for sio/uart and lpt. Anyone using ISA network, storage, sou= nd, > > etc is probably ok building a custom kernel. > >=20 > > My fist thought when I saw this thread was "I hope someone doesn't = ask to > > remove ISA support". >=20 > ISA support simply cannot be removed from the tree, full stop. It is = our > generic bus on x86, and many things that don=E2=80=99t have a better = attachment are > attached here. While some movement towards ACPI has happened here, we= > haven=E2=80=99t done a good job of cutting the cord here because thin= gs work well > enough for people to focus on other things. >=20 > Most, but not all, ISA network, storage and sound drivers have loadab= le > modules, so could easily be loaded at boot should someone wish to run= > GENERIC and still have these devices supported. So there=E2=80=99s a = back-door to > getting a system recovered from modern boot media (assuming, of cours= e, > that these systems could boot off modern boot media). >=20 > In addition, many of the ISA drivers are also PC Card drivers. I stil= l get > many questions about PC Card devices and drivers. At least with PC Ca= rd, > though, we could automatically load the right .ko 95% of the time. Bu= t 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 s= ome > drivers would need a lot of work. USB, PC Card and ISA PNP could do i= t, > with some special marking of the arrays. Old-school ISA, where we hav= e > 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 loa= ded > based on the presence of hints). >=20 > So it is for all these reasons I don=E2=80=99t 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/of= f once > the right build knobs are in place (since it already was close to bei= ng > trivial to get rid of). >=20 > Warner I guess I was a little unclear. What I meant was I think it is fine if = we we=20 remove all ISA network and storage drivers from GENERIC, so long as the= y=20 remain in tree so they can be loaded as modules or compiled into custom= =20 kernels. I'm well aware that ISA provides essential functionality on i386, so we= can't=20 get rid of ISA bus support. I consider that topic off the table. I perh= aps=20 caused confusion in the last sentence. What I meant there was "I hope s= omeone=20 doesn't ask to remove all ISA device support from GENERIC", as in the s= erial=20 ports and floppy controller specifically.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5384422.Lmm1UmY4VK>