Date: Wed, 03 Jun 1998 22:42:38 -0700 From: Mike Smith <mike@smith.net.au> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: eivind@yes.no (Eivind Eklund), mike@smith.net.au, paterno@dsi.UNIFI.IT, freebsd-stable@FreeBSD.ORG Subject: Re: PnP support for if_ed, and more... Message-ID: <199806040542.WAA00634@antipodes.cdrom.com> In-Reply-To: Your message of "Thu, 04 Jun 1998 05:04:03 %2B0200." <199806040304.FAA08620@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Wed, Jun 03, 1998 at 12:09:05PM -0700, Mike Smith wrote: > > > It's erroneous to use device-specific PnP ID's when the generic > > > fallback ID is available. > > But this is not always the case: e.g. the OPTI931 audio card does not > seem to have a fallback ID in the PnP description . So in the end, i > think it is always better to use the specific PnP ID. > My experience with audio cards is that devices are sufficiently > different from each other to require the specific id's. I'm sorry, but I disagree with this entirely. If you need the specific ID, by all means use it. Think of it like a quirk entry - if the generic ID says "this is an NE2000 clone" and you don't have a specific ID match telling you otherwise then you're stupid not to go with the generic ID. > But i don't think it is worth the effort to implement a full scan of > the PnP info. What I think we would really need is a simple > mechanism (perhaps in userconfig) to list vendor_id's known to the > kernel, and map new id's to know ids. > > Something like > > boot> pnp ls id > 0x3600630e CS4236 > 0x3000a865 Yamaha SA3 > 0x3109143e OPTi931 > boot> pnp map 0x3500630e 0x3600630e > boot> pnp ls id > 0x3600630e CS4236 > 0x3000a865 Yamaha SA3 > 0x3109143e OPTi931 > 0x3500630e --> mapped to 0x3600630e > > Wouldn't be too hard to add (just set up a list of id's, to fill up with > DATA_SET in the kenrel, and modify userconfig to add the above > commands), and it is sufficiently flexible to add new 'compatible' > devices. Linking this into the kernel would be bad; it ought to be read from a file. I think I am close to having BIOS disk access working at least from userconfig and other early-kernel places (interrupts are a concern), if this approach is favoured. An alternative (and probably better) method would be for the third-stage bootstrap to do a PnP scan and save the relevant entries from this file for reference by the kernel. This hinges on the three-stage bootstrap, which I haven't done anything with this week yet. > > Eivind, who added the original if_ed PnP code (port from sio). > > Luigi, who added kernel PnP support :) Mike, who complains a lot about PnP. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806040542.WAA00634>