Date: Fri, 12 Sep 1997 16:21:58 +1000 From: Mike Smith <mike@smith.net.au> To: freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <199709120622.QAA01532@word.smith.net.au> In-Reply-To: Your message of "Fri, 12 Sep 1997 05:49:01 GMT." <199709120549.WAA09342@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(cc: trimmed) > > > 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. > > He was talking about reating such hardware as an extension within > the PnP framework: ie: relocate anything that can be relocated, > not just anything that can be relocated via PnP. That's not an issue unless you are making permanent changes. > A specific example might be a AE-3 ethernet card and DOS. Change > the IRQ on the card, and when DOS comes up, the driver load in the > AUTOEXEC.BAT has the wrong IRQ parameter. Really? Who does Artisoft's hardware these days? They shouldn't. Is the AE-3 another 8390x design, like the AE-2? If so, and unless they have their own ISA interface, you can only reconfigure the hardware by munging the onboard EEPROM, not something that's likely to happen with FreeBSD. (Especially as you have to reset the device to force it to reload). Also, if the card can be soft-set on the fly, the driver should be reading the setting out of the card and using that, or coercing the card to match the commandline setting. Allowing irreconcilable redundant configuration is an unforgivable design error. > > 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. > > Actually, that's exactly what were were talking about when we started > talking about relocating non-PnP soft configurable devices. No, I don't believe it is. "relocating" to my mind involves taking a device and moving it _right_here_and_now_. What you are talking about is an out-of-band reconfiguration, ie. you reconfigure the device and then reboot, wherupon it takes up new parameters. > > > 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. > > If you look at the hierarchy I denoted in my previous posting > (it looked like a directory tree), you'll see that you are saying > the exact sam thing I just said. 8-). Whoops. I was obviously misremembering the tree in question. MHA. > > 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. > > Cool. This is exactly the soloution I think is called for. Let > me know how it goes; if you have specific changes you want tested, > I can probably help out. Sure. -current builds OK today, so I'm off hunting JL's BIOS call stuff as I write. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120622.QAA01532>