Re: User asks: can we decouple device vendor IDs from drivers?
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) 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/... 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 :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User asks: can we decouple device vendor IDs from drivers?
In message: [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
User asks: can we decouple device vendor IDs from drivers?
Hi,
This sounds like one for the NEWBUS people.
BMS
---BeginMessage---
In message [EMAIL PROTECTED], Bruce M Simpson wrote:
Hiya
To follow up what I said down the pub...
The file in solaris i was referring to is called /etc/driver_aliases
do a search to find out about it.
Looking at the mess in FreeBSD device drivers and how the drivers
decide to attach to a device or not, then a lot of effort would
be needed to clean those up, but should an alias file such as the
solaris one exist in FBSD, IMHO it would make the life of everyone
much easier.
Perhaps you should look into it and propose to the FBSD team about
implementing something sane like this, hacking every driver to
add a new device ID is really a pain.
Cya
--
// /
{:)==={ Darron Broad [EMAIL PROTECTED]
\\ \
---End Message---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User asks: can we decouple device vendor IDs from drivers?
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : This sounds like one for the NEWBUS people. A number of people have proposed this in the past. It is a big deal, and won't be in 5, although a 'treat this pnpid as that pnpid' might be, which would be sufficient. 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. The other down side is that when you bork the alias file on solaris, you are so hozed. However, it would make the dynamic loading of drivers easier. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
