Messages in this thread | | | Date | Thu, 9 Mar 2000 14:31:12 -0500 (EST) | From | Peter Rasmussen <> | Subject | Re: PNP design philosophy? |
| |
>> "Richard B. Johnson" wrote: >> > >> > I don't understand how you could possibly have an AGP card on an i386 or >> > any PCI or USB. Perhaps you are referring to "ix86"?? > >> If you want to split hairs I could say I don't know what architecture your >> i686 is? One of the architectures in the standard Linux kernel tree is >> listed as "i386" (without the quotes), but there is no i686. > >Was not splitting hairs. If somebody has a problem, it helps to be >specific. > And how is mentioning a machine as i386 when asking about Linux kernel code not specific? And how would saying ix86 making it more specific?
>> > >> > The keyboard/mouse/serial/parallel are all handled by the kernel. There >> > is no dependence upon the BIOS. I note that startup code insists in using >> > the BIOS to set the keyboard repeat-rate, but that can be handled by >> > the kernel after the system is booted so even it it didn't work it can >> > be fixed once the system is up. > > >> So what you are saying is that there is no dependance on the BIOS at all or >> for the keyboard/mouse/serial/parallel part only? > >Correct. The BIOS is never used. > So when a BIOS setting in one way can make something possible and in another way make it non-possible makes it dependant on the BIOS, whether it is used or not. That is the problem.
>> Turning off PNP in an i386 BIOS usually means turning off ISA PNP and as far >> as I can see we don't limit ourselves to just that. >> > >Sure. But remember "Plug and Play" (Plug and Pray) never worked for >anybody, expecially Micro$oft. The drivers all go out and probe. The >major reason is that there are often not enough physical traces on the >motherboard going to the slots. Often (usually) you have to move cards >around to have them found, and found in some useful way. > Uhm ... I don't get what you mean? When a BIOS has ISA PNP code in it it goes out and initializes the cards in a way well described in the Plug-and-Play-HOWTO where I didn't see any mentioning of card-position being relevant and I would be very surprised if it did, but please elaborate if you want to.
Further, I have no knowledge about Microsoft's products and I believe the ISA PNP specs were produced by Microsoft, Intel and Compaq in unison. It is a hack of an outdated bus, yes, but it is unfortunately something some of us are stuck with and hope to make work in a useful way.
>> What you are saying above is that the PNP code *is* dependant on the BIOS and >> that is what worries me because it makes it pretty non-general. > >That's your interpretation. I stated that information from the BIOS is >made available to the kernel. I also stated that you can sometimes >override this information. I can't understand how you could interpret me >differently. > My mistake, I am sorry. When I said "PNP code" I meant Linux kernel PNP code, which is dependant on BIOS settings, if any change of the settings there will affect how the kernel is able to work. At least that is how I interpret the meaning of the word "dependant".
>> services provided by PNP and that I can override bad info on the command line >> with some drivers? But I don't think that a driver can or should change >> for example the IRQ, DMA or IO port the physical device has been initialized >> with, because that is what the PNP code does, right? >> > >There are no "services" provided by PNP. There are a bunch of software >hacks in the BIOS, many of which can't possibly work. That's why PNP >doesn't work. The kernel code attempts to work around these problems. > Again, I am sorry I didn't specified that I meant Linux kernel PNP code when I said PNP code. I would hope that after the Linux kernel PNP code finishes with its initial resource management, all drivers that need access to for example physical devices would be able to get them from the Linux kernel PNP code as a service, instead of having to query the actual device itself. Otherwise I don't see the purpose of PNP in the kernel?
All in all, it would be great if the kernel could start over with initializing all hardware devices, possibly with a 'good start guess' from what was there previously if it for example was an i386 with a PNP BIOS, but not limited to that. When all devices were initialized, drivers that needs access to a device would ask Linux kernel PNP for it and never know if it was a PCI, AGP, ISA, VME or SBUS device for all I care.
Or is this not what PNP support and resource management in the Linux kernel was meant to be?
>> > Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips). >> Linux version 2.3.50 on an i386 machine (466.94 BogoMips). And what does that >> tell us? :-) >> > >Erm... I have a Dual SMP machine with a 400Hz internal clock. You have a >single CPU, that's supposed to run at 400 MHz, but it seems to be >overclocked. Further, you are running an experimental version that >probably has fewer bugs than mine. > Good joke :-) (You are joking, right? :-) My machine is a 233MHz P5)
Thank you very much,
Peter -- main(){char*s="O_>>^PQAHBbPQAHBbPOOH^^PAAHBJPAAHBbPA_H>BB";int i,j,k=1,l,m,n; for(j=0;j<7;j++)for(l=0;m=l-6+j,i=m/6,n=j*6+i,k=1<<m%6,l<41-j;l++) putchar(l<6-j?' ':l==40-j?'\n':k&&s[n]&k?'*':' ');}
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |