Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Aug 1998 08:36:52 +0200 (CEST)
From:      Søren Schmidt <sos@FreeBSD.ORG>
To:        roger@cs.strath.ac.uk (Roger Hardiman)
Cc:        rhh@ct.picker.com, ahasty@rah.star-gate.com, multimedia@FreeBSD.ORG
Subject:   Re: Putting the bt848 driver into the GENERIC kernel
Message-ID:  <199808130636.IAA00393@sos.freebsd.dk>
In-Reply-To: <35D24B2D.9DB2C577@cs.strath.ac.uk> from Roger Hardiman at "Aug 13, 98 03:10:53 am"

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Roger Hardiman who wrote:
> Randall, Amancio, Multimedia's
> 
> I was wondering why we do not have the bt848 driver in the GENERIC
> kernel.

There are several good reasons why this isn't the case, and why the
GENERIC config is like it is.
First there are HW that needs to be probed in the right sequence to
avoid hanging up other HW that might use the same address space or
other resources. Then there is the space issue, the GENERIC kernel
plus install tools HAS to fit on a floppy with limitted space.

Then in this specific case there are a couble more problems.
The bt848 driver has close to no probe code, ie it will fail to 
recognise the card in say 80% of the cases (in fact besides the
newest cards it fails utterly), giving the user a hell of a time
trying to figure out what is wrong.
Then we need sound, erhm, that is not much easier to do a generic
setup for. Granted if we used Luigi's drivers we would have support
for most generic cards, so that might work.

As much as I would like the GENERIC kernel to have all this functionality
built in, equally much I see all the problems its uncovers.

We could change the bootfloppy to use another (BOOTGENERIC) kernel
and then have the system install another (BIGGENERIC) kernel from
the bindist when the install is done, that change would be trivial
and give the space needed for extra drivers.
But until the bt848 driver can make sense out of a significant bigger
fraction of the HW, I'd really recommend against this, as it will
only bury us under a truckload of errorreports from the (new)users.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt               (sos@FreeBSD.org)               FreeBSD Core Team
                Even more code to hack -- will it ever end?
..

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808130636.IAA00393>