Date: Thu, 11 Sep 1997 14:25:44 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Terry Lambert <tlambert@primenet.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, mike@smith.net.au, perhaps@yes.no, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <19970911142544.37798@hydrogen.nike.efn.org> In-Reply-To: <199709111815.LAA24444@usr07.primenet.com>; from Terry Lambert on Thu, Sep 11, 1997 at 06:15:32PM %2B0000 References: <199709111524.RAA00618@labinfo.iet.unipi.it> <199709111815.LAA24444@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert scribbled this message on Sep 11: > 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. oh.. this isn't hard at all (except for when we panic, but FreeBSD never does that does it?? :) ).. you just call ALL the devices' detach routines before shutting down... then the device gets relocated 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. this is slightly more problematic.. as we can't very easily make sure than the boot device (that would contain all the dynamicly loadable modules with this info) will be on a bus that was attached before this device... but if we can.. we simply load and use that device specific information.. > 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. unless you tell it to go beyond... who cards about running other os's on your machine?? :) > > 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. hmm... so we have a flag on the list of resources that a driver uses... if it's set, then the resource is ONLY used when the device is open.. otherwise that resource is used all the time... this works nicely for com ports.. as the ioaddress space is always in use... but the irq is only used when needing to recieve data... the device open will be more complex.. we will have to include something like a check on the first open... thanks for point this out... I"m going to add this to my spec... > > 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. hmm.. very good point... so we need to make sure that upon a failed attach that the device will leave the structure with a correct list of resources that are active... i.e. most likely just the iobase and memory mapped space... but it coulde leave irqs active... if they do, we should probably make a small routine that will catch these "stray" irqs and not through them in with the generic stray ones.. > 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. umm.. you lost me there.. you mean that some motherboards ACTUALLY present the hardware emulation of the PnP card for legacy isa hardware? I really have a feeling that you didn't mean this... > > > 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. hmm... I probably should, could you mail me the reference in private email? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970911142544.37798>