Date: Sat, 01 Nov 2003 12:22:18 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: mark@grondar.org Cc: freebsd-hackers@freebsd.org Subject: Re: User asks: can we decouple device vendor IDs from drivers? Message-ID: <20031101.122218.13771065.imp@bsdimp.com> In-Reply-To: <200311011013.hA1ADH4L032554@grimreaper.grondar.org> References: <20031031.125753.124085663.imp@bsdimp.com> <200311011013.hA1ADH4L032554@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200311011013.hA1ADH4L032554@grimreaper.grondar.org>
Mark Murray <mark@grondar.org> writes:
: "M. Warner Losh" writes:
: > The problem with decoupling things entirely from the drivers is that
: > many drivers will say "if I have this revision of that card, do this
: > workaround." or "if I'm this or newer, I have this feature" both of
: > which are broken by the kernel forcing the driver to service a given
: > hunk of hardware.
:
: Hmm. Careful design may sort this out, methinks. If the file (which
: sounds analagous to /boot/device.hints to me) turned devid's into
: generic griver requrements (DEVID(0x04589045) == driver(foo) revision(bar)
: flags(baz, qux)) would that not be usable? (/me wonders if he has the time
: to do this - he's certainly interested)
I think you miss the point of my objection. It isn't to match the
card. That's trivially easy to do in a config file like the hints
file (boot loader). The problem is that drivers often have code that
looks like:
if (id == CARD_3C589)
set some flags
else if (id == CARD_3C572)
set some flags
else
some defaults.
Now then, if 3com comes out with a new card that's like the 3c572 (say
the 3c574), then the driver still has to be changed to grok the new
card.
However, if you say 'map this id to that id' then you could say 'map
3c574 to 3c572' and the driver would just work.
See the difference? In your case, the default flags would be set, and
the device would fail to work. In my case the driver thinks it is
talking to a 3c572, and sets the flags correctly for that card.
Maybe you need both, but the mapping feature is critical.
Also, you need to do the same sorts of matching functionality that
devd has to match things. If this replaces the 'probe' part of the
system, then you also have to deal with those busses that aren't
self-identifying.
: > The other down side is that when you bork the alias
: > file on solaris, you are so hozed.
:
: ... like most of the files in /boot/...
No. You can boot if /boot is f*'d up fairly easily. If all the
driver information is codified in one file, then you are one file away
from having a totally hozed system. With the rest of the files in
/boot/ there typically is a backup file that you can boot, ditto with
kernel vs kernel.old.
I've been ass raped by missing /etc/driver_aliases file on solaris
many many times. I'm not keen on making it easier for freebsd to do
this to its users.
: > However, it would make the dynamic loading of drivers easier.
:
: I really like to concept of configuring things with vi(1), instead of
: with gcc :-)
You can like that concept all you want. It is not completely
appropriate to the driver stuff. There's typically only one or two
drivers in the tree that have a large traffic in adding devices: ed
and wi. Most of the other drivers in the tree do need occasional
devices added, but
There's actually a lot of work here to make this work right, and I'm
not trying to get in the way of it. I just don't want to wind up with
a half-assed system in the end.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031101.122218.13771065.imp>