From owner-freebsd-hackers Wed Jul 10 22:06:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA15144 for hackers-outgoing; Wed, 10 Jul 1996 22:06:52 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@mindbender.headcandy.com [199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA15139 for ; Wed, 10 Jul 1996 22:06:49 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.7.3) with SMTP id WAA02216; Wed, 10 Jul 1996 22:06:29 -0700 (PDT) Message-Id: <199607110506.WAA02216@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: John Fieber cc: "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: Some recent changes to GENERIC In-reply-to: Your message of Wed, 10 Jul 96 17:11:41 -0500. Date: Wed, 10 Jul 1996 22:06:28 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> sio2 >> sio3 >Some people have modems on sio2 or 3 because the UARTs on sio0 >and 1 are crappy unbuffered ones. For these people, eliminating >sio2 and 3 may not be a complete showstopper, thanks to the -c >boot option, but it is a hassles regardless. We are trying to >make installation easier, not harder aren't we? Considering that >a modem may be instrumental in installing FreeBSD for some >people, I'd hope these could stay in unless there is a *really* >good reason to zap them. The point isn't whether it's inconvenient. The question is really if it is a showstopper. While it might be slightly inconvenient for Joe Blow to move his/her modem to a slower serial port temporarily, it's better than having someone's machine go totally dead just trying to boot, which is the situation some people face when com4 (going by DOS numbering here) is in the kernel. Under NetBSD's com driver, there were many reproduceable cases where probing com4 would totally whack out the display (if not the whole machine -- I don't remember), and make the install kernel unusable. >From what I'm hearing, it sounds like the same thing is happening with the FreeBSD sio driver. The hard truth is: some people *can* *not* boot with com4 in the kernel. This typically happens with ATI MachXX and some S3 video cards. Wouldn't it be better if the com/sio drivers were made to probe in a way that wouldn't kill these video cards? Heck yeah! But currently, they don't, and I'm not sure if anyone knows what the secret combination is, anyway. Wouldn't it be better if we could just dynamically load and unload these as kernel modules? Yeah, that would be cool too. But, to my knowledge, that isn't possible with the current driver code. There are a ton of better things we could do, but many of them are accomplished with code that doesn't currently exist. Is it *really* that big a deal? I've heard lots of hyptheticals so far, but I haven't heard anyone yet say "*MY* machine will break if you take these ports out." ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. -----------------------------------------------------------------------------