From owner-freebsd-hackers Wed Jul 10 10:21:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27544 for hackers-outgoing; Wed, 10 Jul 1996 10:21:42 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA27533 for ; Wed, 10 Jul 1996 10:21:34 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA23842; Wed, 10 Jul 1996 11:21:15 -0600 (MDT) Date: Wed, 10 Jul 1996 11:21:15 -0600 (MDT) Message-Id: <199607101721.LAA23842@rocky.mt.sri.com> From: Nate Williams To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: Re: Some recent changes to GENERIC In-Reply-To: <12325.836972831@time.cdrom.com> References: <12325.836972831@time.cdrom.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Back to the original article ] > After speaking with David on the phone, I decided to remove the > following entries from GENERIC: > > sio2 > sio3 > lpt2 > mcd1 > lnc1 > > I would also like to remove: > > ed1 > lp1 > > But will wait for more feedback on that (I think that ed1 should at > least go). I've undertaken this housecleaning because I feel that > GENERIC has built up more than its fair share of historical cruft > (many of the doubled entries predating userconfig) and we need to get > back to the concept of GENERIC as a "just get it installed with as > little wasted space as possible so that it still fits on one boot > floppy" kind of kernel image. Having worked with BSD/*nix systems since the mid-80's, as I understand it GENERIC wasn't intened to be a 'minimal' kernel with as little wasted space as possible, but a 'kitchen-sink' kernel which contained every conceivable driver so that you could never had to build a custom kernel for your system unless you had special needs. I know that I never *had* to build custom kernels on *any* of the commercial BSD systems I've used unless I had a very special need. (Like adding in un-supported SLIP support, etc..) Making folks build their own custom kernels is a step in the wrong direction. We should be providing 'out-of-the-box' solutions solutions for them in the same manner as pre-built ports. If getting source and building it from scratch wasn't an issue we shouldn't even be providing pre-built ports since it's so easy to build them w/out an Internet connection on the CD already. Other free *nices don't *make* the user build their own custom kernels for standard PC hardware, and most PC hardware now have > 2 serial ports when you consider almost *EVERY* single PC now has the standard 2serial/Parallel/game-port plus an internal modem. Since you already brought in the 'disable' keyword, why don't you simply disable sio2/3, and leave them in. As far as the remaining ones go, I don't know of any *standard* PC that has more than one parallel port, so I see no need there, and I also doubt that anyone has multiple Mitsumi-CD's on their system. I'm only concerned about the 2 (now missing) serial ports, which can be safely disabled/enabled by the end user w/out requiring a kernel re-compile with the config changes. I suspect this is less than 1K in the kernel with the advantage of not having the end-user *require* a kernel re-compile for her system. Nate