Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Sep 2008 00:27:18 +0200
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        alfred@FreeBSD.org, freebsd-arch@FreeBSD.org
Subject:   Re: dynamic update of usb/pci/quirks tables
Message-ID:  <20080928222718.GA56058@onelab2.iet.unipi.it>
In-Reply-To: <20080928.161010.1649769915.imp@bsdimp.com>
References:  <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com> <20080928201948.GE36572@elvis.mu.org> <20080928.161010.1649769915.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 28, 2008 at 04:10:10PM -0600, M. Warner Losh wrote:
> In message: <20080928201948.GE36572@elvis.mu.org>
>             Alfred Perlstein <alfred@freebsd.org> writes:
> : * M. Warner Losh <imp@bsdimp.com> [080928 13:01] wrote:
...
> : > Maybe it will work out for the other tables you want to update, but it
> : > won't work well for device tables.
> : 
> : I really like the idea of using a kmod to just add the new device
> : strings.. (some form of what Hans did).
> 
> The problem is that except for the most trivial driver, that doesn't
> work.  Most of the NIC drivers in the tree do special things based on
> what chip they thing they are talking to.  An unknown chip may work,

it really depends on what you are looking at -- in some drivers the
"special things" are called inline in the code looking at the device IDs;
in other drivers, they are implemented as functions that are called
depending on the content of the quirks info, so the behaviour is
(or aims to be) entirely table driven.

In this respect I believe USB stuff tends to be more table-driven
(probably because there is also a huge variety of devices,
and the inline approach wouldn't scale well).
NIC drivers are different as most of them are derived one from
another by copying and modifications, and there wasn't always a lot
of design involved in making them generic and configurable -- nor
was it worth the effort once they are working (and i don't mean
to blame anyone -- there is no point to optimize a driver for a
broken piece of hardware if you can get better hw).

cheers
luigi



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