From owner-freebsd-arch@FreeBSD.ORG Wed Apr 16 17:15:56 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C3F625D for ; Wed, 16 Apr 2014 17:15:56 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DDB4E1867 for ; Wed, 16 Apr 2014 17:15:55 +0000 (UTC) Received: from 93-153-61-159.tmcz.cz ([93.153.61.159] helo=desktop.reztek) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WaTRA-0009Xo-Q1 for freebsd-arch@freebsd.org; Wed, 16 Apr 2014 17:15:52 +0000 From: Matthew Rezny To: freebsd-arch@freebsd.org Subject: Re: EISA in GENERIC Date: Wed, 16 Apr 2014 19:15:44 +0200 Message-ID: <5384422.Lmm1UmY4VK@desktop.reztek> Organization: RezTek, s.r.o. User-Agent: KMail/4.12.3 (FreeBSD/10.0-STABLE; KDE/4.12.3; amd64; ; ) In-Reply-To: <421F815B-906C-4CD0-8D5B-349FBD5B6607@bsdimp.com> References: <7524617.WO5TPN2b6E@desktop.reztek> <421F815B-906C-4CD0-8D5B-349FBD5B6607@bsdimp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 93.153.61.159 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:15:56 -0000 On Wednesday 16 April 2014 10:56:42 you wrote: > On Apr 16, 2014, at 10:36 AM, Matthew Rezny wrote= : > >> Warner Losh 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.