Date: Fri, 12 Sep 1997 14:32:28 +1000 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo), mike@smith.net.au, gurney_j@resnet.uoregon.edu, perhaps@yes.no, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <199709120432.OAA01173@word.smith.net.au> In-Reply-To: Your message of "Thu, 11 Sep 1997 18:15:32 GMT." <199709111815.LAA24444@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Also, while we are on the subject: some legacy ISA device also have > > software-configurable resources such as DMA or IRQ channels. methods > > are device-specific (pre-PnP). > > This is a hard problem. > > The reason that this is a hard problem is that dynamic reconfiguration > of dynamically-reconfigurable-but-not-PnP hardware makes it difficult > for FreeBSD to coexist with other OS's, which would not know about > these devices ability to move around. This is actually such a trivial issue that I don't consider it worth worrying about. If you have a particular OS in mind, and a specific test case to demonstrate your problem, a workaround might be in order. > Another issue is that the static state for allowable configurations > must be kept in the device driver, and it makes the device drivers > just that much less general. For example, the soft configuration > of most NE2000 clone cards varies from vendor to vendor. That's > a lot of data. These configurations are generally read from external EEPROMs on device reset. Rebooting involves such a reset, and it is unlikely that FreeBSD will be rewriting said EEPROMs in the near future. > > > I think it's important to leave the 'legacy' devices until _last_, as > > > this prevents a PnP device being accidentally recognised as a 'legacy' > > > device. > > > > Right. > > > > Comments ? > > You probe up the hierarchy, and attach down. Pretty simple. No. You probe from least intrusive to most intrusive, and use the lesser intrusive probes to eliminate places for sticking your fingers. > Note: You are screwed in this case if you do not have a PnP BIOS > that knows about legacy hardware for which the OS has no drivers; > to be able to deal with this issue, you need a "BIOS config" in your > PnP OS. This is where the ECSD stuff comes into play on modern systems. I am trying to world as we speak so that I can start using Jonathan's vm86 BIOS call support to talk to this. > I *highly* recommend that anyone coding on this obtain a recent > copy of the PnP specification, and consider these issues in their > design. As was pointed out by someone else, if you don't, it will > have to be rewritten later, and the new code, if marginally more > functional, will act as a speed-bump, impeding geting it right. I will simply add : read the spec many times. It's confusing and poorly structured, but you will want to actually have a _feel_ for what is going on, as well as just knowing which page the structure definitions are on. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120432.OAA01173>