Date: Tue, 1 Oct 1996 19:11:48 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, bde@FreeBSD.org, current@FreeBSD.org Subject: Re: Your UserConfig changes for unmasking PCI devices... Message-ID: <199610020211.TAA03048@phaeton.artisoft.com> In-Reply-To: <199610020200.LAA17100@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 2, 96 11:30:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > If this doesn't have any unwonted side-effects, sure! > > > > I believe it would have the side effect of making relocatable PCI > > devices immovable, potentially resulting in name space (DMA, IRQ, MEM) > > conflits with ISA device that would require physically openning the > > machine to fix. > > Huh? What crap is this? Moving userconfig close to the ISA probes has > nothing to do with whether "potentially relocatable" PCI devices can > be stuck sideways up the user's nostril. > > Unless/until the PCI support code starts taking over from the BIOS in > regard to controlling IRQ mapping across PCI-ISA bridges, the space > from which PCI devices can be allocated IRQs cannot (by definition) > overlap with the IRQ which are available to ISA devices. Under this > scheme, if an ISA device is misconfigured (ie. it has an IRQ that is > free for use by a PCI device), it's gonna stay misconfigured until > it's manually corrected, regardless of at which point in the boot > process the user is offered the option of changing the parameters for the > driver which may end up talking to it. Obviously, the PCI support code wants to be able to relocate PCI devices. In general, BIOS is too stupid to set up PCI to avoid existing ISA devices bridged on the motherboard, let alone ISA device you plug in (like, oh, say, a GUS card). > > This is the problem with continuing to support ISA in otherwise decent > > hardware designs. > > And fire is hot. Care to wave any other examples of the bleedin' obvious > around? Regardless, some people are actually making headway with this > sort of thing. I'm loth to do much more with userconfig because it's > the wrong way to go. I'm watching GRUB with mild interest, but I think > it doesn't go far enough. GRUB is interesting. OpenBoot is more interesting. Passive PCI backplane based hardware is most interesting. > > I suspect that the best compromise would be to leave it alone (since it > > is just noisy, not harmful) until the bus probes can be completely > > seperated from the bus drivers. This would let you only put up PCI > > messages when a PCI bus is found (or EISA for EISA, PCMCIA for PCMCIA, > > etc.). > > The idea of seperating the probe and attach/support code for a driver, > or at least making them seperately callable, is very attractive. If > we ever go for a kernel approach where the last-stage loader (I call > it "strap" in what passes for my grand plan) has BIOS access to the > disk and assembles the kernel (maybe from ELF segments) in memory > before launching it, then this will be a useful and wonderful thing. Yeah; I'm not holding my breath. 8-). > But all this has been done to death already. Yes, it has, which is why disabling the PCI messages (which would otherwise encourage fixing things The Right Way 8-)) would be A Bad Thing. 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?199610020211.TAA03048>