Date: Wed, 2 Oct 1996 11:30:29 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: 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: <199610020200.LAA17100@genesis.atrad.adelaide.edu.au> In-Reply-To: <199610012147.OAA02571@phaeton.artisoft.com> from "Terry Lambert" at Oct 1, 96 02:47:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > > > Ah, how about putting off calling userconfig() until after the PCI and > > > EISA probes? Since it's only _really_ relevant to the ISA probe > > > process, shouldn't it be directly associated with it? > > > > 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. > 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. > 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. But all this has been done to death already. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610020200.LAA17100>