Date: Thu, 11 Sep 1997 18:15:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: mike@smith.net.au, gurney_j@resnet.uoregon.edu, perhaps@yes.no, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <199709111815.LAA24444@usr07.primenet.com> In-Reply-To: <199709111524.RAA00618@labinfo.iet.unipi.it> from "Luigi Rizzo" at Sep 11, 97 05:24:55 pm
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. I would still like to see a device level driver entrypoint for configuration control for these devices (especially, I'd like to see one accessible by ioctl() for WD ethernet cards!), but I'm not willing for this t be converted into something that will relocate cards that another OS will be unable to relocate back. 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. The one exception to allowing auto relocation *might* be for the case of an otherwise unresolvable hardware conflict. Even then, I hesistate to agree that the OS prompting the user with a stern warning before the change is sufficient: just because the hardware will accept a given configuration doesn't mean another OS's drivers will be able to accept the configuration. Going back to the NE2k clone example, many NE2k clones allowed IRQ ranges out of range of various OS's NE2k drivers: FreeBSD was one such OS in the not too distant past! I would definitely caution against this. If people want to be *certain* beyond a shadow of a doubt that their hardware will work with FreeBSD, without damaging the ability of the hardware to work with another OS without reconfiguration, then they should avoid ISA cards entirely. FreeBSD should do what it can, within the "do no harm" constraints above... but should not go beyond. > ALLOCATE: > Before going on with the attach, we have to take a decision among > the available options and then just go on with the attach routines, > marking those devices which could not be allocated the requested > resources ? This is also frustrating. From the above, an ISA sound card and an ISA network card, one of which is sof reconfigurable and neither which are PnP, or a serial port COM1 and a modem COM3, both of which want IRQ 4, and one of which is soft reconfigurable and neither are PnP, are both examples. The simple answer is that you can't move these, even though they conflict, without potentially damaging the configuration of another OS. For example, with the COM ports, if 1 and 3 are never used simultaneously, many OS's can cope with the conflict by never enabling interrupts on both simultaneously. Or by polling. So while the configuration is not optimal, neither is it entirely unusable. > here if some attach fails we can free the resources which have been > allocated for them, and possibly go back to ALLOCATE: if any device was > left out ? Only if the failing device can be disabused of the resources it's known to use. This will only work for PnP devices, where the card may be disabled, and then only in the case that the OS provides PnP BIOS type services to do the port diddling necessary to shut the device down. Otherwise, the failing device must be assumed to be activated. Note that a PnP BIOS for a particular board may have ISA devices defined as if they were PnP devices, in order to consider them in the PnP conflict resolution phase. Though these devices appear to be PnP devices, and therefore you might believe that you could disable them if you didn't have a suitable driver, and reclaim their resources, you CANNOT. They will not obey the disable requests. Thus PnP BIOS alone is not enough; an OS must provide its own PnP BIOS type services to be able to distinguish these devices. > > 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. 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. Even if you have a PnP BIOS, you still need this: Windows 95 universally fails to identify IRQ 12 as being used by the Bus mouse in some Acer machines, and reallocates it. The OS must compensate. Windows 95 "compensates" by requiring you to lock down all PnP devies in the device configuration in the Properties page for "My Computer". FreeBSD can, and should, do better. Maybe a PnP legacy device configuration in "boot: -c/visual". 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. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709111815.LAA24444>