Date: Wed, 10 Jul 1996 22:06:28 -0700 From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@HeadCandy.com> To: John Fieber <jfieber@indiana.edu> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, hackers@freebsd.org Subject: Re: Some recent changes to GENERIC Message-ID: <199607110506.WAA02216@MindBender.HeadCandy.com> In-Reply-To: Your message of Wed, 10 Jul 96 17:11:41 -0500. <Pine.BSF.3.94.960710170116.4397A-100000@Fieber-John.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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.
-----------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607110506.WAA02216>