From owner-freebsd-arch@FreeBSD.ORG Wed Apr 16 16:56:52 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46C9CAA0 for ; Wed, 16 Apr 2014 16:56:52 +0000 (UTC) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11598167E for ; Wed, 16 Apr 2014 16:56:51 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id ur14so1264267igb.14 for ; Wed, 16 Apr 2014 09:56:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=oh3aeOGiccJ/4SSl1DKSDjYqHLelv2F7WhQVSONqqAI=; b=CKrXqV6WzNB3Ffaw53nuJ+WRyBXZiJ2801f5LiDgEXw7bR+W2MVybi2xRBtqrcJvWp uiT2prIKLuIj7XLXeWQQIotaceB6b2i8tvKfu1+nQ/Myd8VPcyyv7wwAD3g5XtyKZNsD IBWRtMjgUHLJZlVBxGVbaRRzk1+R38rej0ggGBll7DpCBrAbdiK/KLRsPSraGWReJyEX DjSDXcRS7WiSgPDk8iyLjk5h27r+5SlBt5R8pczDp9ysvVrna35OXY1xg/RFvXKWoWMF IcTzc7AG+MS6BMYdqv6VzbyHj+EP/8ORGg9lh+zMK1zIUQJ5341ez3Eii+VJ0p0JcWI0 VPSg== X-Gm-Message-State: ALoCoQnCuXFNk9RjNrfYDOqaUCG9xvrDxZvv77Av8scPqxYVdYuxn/p7m+9uPNM3AdW/l7t55bsU X-Received: by 10.50.22.210 with SMTP id g18mr6069076igf.19.1397667405053; Wed, 16 Apr 2014 09:56:45 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id s1sm45747879igr.14.2014.04.16.09.56.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 09:56:44 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: EISA in GENERIC From: Warner Losh In-Reply-To: <7524617.WO5TPN2b6E@desktop.reztek> Date: Wed, 16 Apr 2014 10:56:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <421F815B-906C-4CD0-8D5B-349FBD5B6607@bsdimp.com> References: <7524617.WO5TPN2b6E@desktop.reztek> To: Matthew Rezny X-Mailer: Apple Mail (2.1874) Cc: freebsd-arch@freebsd.org 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 16:56:52 -0000 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=F8rgrav - 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 = amd64 and=20 > little reason have it in GENERIC for i386. General ISA support needs = to remain=20 > for sio/uart and lpt. Anyone using ISA network, storage, sound, etc is=20= > probably ok building a custom kernel. >=20 > My fist thought when I saw this thread was "I hope someone doesn't ask = to=20 > 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=92t have a better attachment are = attached here. While some movement towards ACPI has happened here, we haven=92t 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=92s 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=92t 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=