Date: Wed, 28 Jan 1998 08:50:08 +1030 From: Mike Smith <mike@smith.net.au> To: Kurt Olsen <kurto@bootp.sls.usu.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed PNP changes Message-ID: <199801272220.IAA00450@word.smith.net.au> In-Reply-To: Your message of "Tue, 27 Jan 1998 12:13:41 PDT." <199801271913.MAA18031@bootp.sls.usu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> After checking out the PNP support in 3.0 and 2.5-STABLE, I came to the > conclusion that it could do more. So here's my thoughts, and hopefully > I'll get something done this weekend. > > The primary changes I want to make: > > 1 - grok the configuration information before USERCONFIG and identify > all LDNs and the resources they want as well as the configuration > values they accept. This isn't as simple as it sounds. You need to be able to call into the PnP BIOS to retrieve the ESCD information for statically-configured devices, and this is where I came unstuck. (The PnP BIOS only provides a 16-bit protected-mode interface, which effectively makes it quite interesting getting back into the kernel afterwards.) > 2 - recognize the compatible tag for devices where we don't have > card specific drivers, but we do have general drivers. ie. I > have a plug and play ethernet card that's been in hardwired mode > for the last year, but it's ne2000 compatible and there's no > reason it couldn't be dynamically configured before the ed0 > probe. This is a subset of a general ID association mechanism. Several implementation concepts have been discussed, but not gotten very far yet. I would suggest a little caution to avoid duplicating effort; at the very least you will want to speak with John-Mark Gurney about the directions his assault on the driver interface are taking. > Any suggestions? Or comments? Any reason why I won't be able to > run the isolation protocol before userconfig? I would strongly advise against blindly running the isolation protocol from scratch. Some more study of the PnP documents (annoying though they are) will reveal that you actually need to cover several different scenarios. Just blindly up and splatting all over the current state of the hardware isn't always the right way to go (unfortunately). -- \\ 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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801272220.IAA00450>