* ISA slot detection on PCI systems?
@ 2002-01-02 20:15 Eric S. Raymond
2002-01-02 20:45 ` Jeff Garzik
` (3 more replies)
0 siblings, 4 replies; 185+ messages in thread
From: Eric S. Raymond @ 2002-01-02 20:15 UTC (permalink / raw)
To: Linux Kernel List
Is there any way to safely probe a PCI motherboard to determine whether
or not it has ISA cards present, or ISA card slots?
Note: the question is *not* about a probe for whether the board has an ISA
bridge, but a probe for the presence of actual ISA cards (or slots).
(Yes, I'm working on a smart autoconfigurator. It's a development of
Giacomo Catenazzi's code, but able to use the CML2 deduction engine.)
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance? Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and tyrants.
-- Thomas Jefferson, letter to Col. William S. Smith, 1787
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: ISA slot detection on PCI systems? 2002-01-02 20:15 ISA slot detection on PCI systems? Eric S. Raymond @ 2002-01-02 20:45 ` Jeff Garzik 2002-01-02 20:46 ` Brian Gerst ` (2 subsequent siblings) 3 siblings, 0 replies; 185+ messages in thread From: Jeff Garzik @ 2002-01-02 20:45 UTC (permalink / raw) To: esr; +Cc: Linux Kernel List "Eric S. Raymond" wrote: > > Is there any way to safely probe a PCI motherboard to determine whether > or not it has ISA cards present, or ISA card slots? > > Note: the question is *not* about a probe for whether the board has an ISA > bridge, but a probe for the presence of actual ISA cards (or slots). ISAPNP. You can tell if ISA cards are present in some cases, but you cannot tell when no ISA cards are present at all. Further, serial and parallel devices are common examples of devices we treat as ISA, which usually aren't. They don't have a slot [usually] but definitely need to be configured. Jeff -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:15 ISA slot detection on PCI systems? Eric S. Raymond 2002-01-02 20:45 ` Jeff Garzik @ 2002-01-02 20:46 ` Brian Gerst 2002-01-02 20:59 ` Alan Cox 2002-01-02 21:28 ` Christian Koenig 3 siblings, 0 replies; 185+ messages in thread From: Brian Gerst @ 2002-01-02 20:46 UTC (permalink / raw) To: esr; +Cc: Linux Kernel List "Eric S. Raymond" wrote: > > Is there any way to safely probe a PCI motherboard to determine whether > or not it has ISA cards present, or ISA card slots? > > Note: the question is *not* about a probe for whether the board has an ISA > bridge, but a probe for the presence of actual ISA cards (or slots). > > (Yes, I'm working on a smart autoconfigurator. It's a development of > Giacomo Catenazzi's code, but able to use the CML2 deduction engine.) The problem with ISA is that it is too simple of a bus, and is virtually transparent. It has no auto-configuration/detection standard (except ISAPNP). Each card is detected in a different way, and you have the problem with probing unknown ports causing potential crashes. Detecting the ISA slots is impossible, except possibly from the BIOS. -- Brian Gerst ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:15 ISA slot detection on PCI systems? Eric S. Raymond 2002-01-02 20:45 ` Jeff Garzik 2002-01-02 20:46 ` Brian Gerst @ 2002-01-02 20:59 ` Alan Cox 2002-01-02 20:46 ` Eric S. Raymond 2002-01-02 21:00 ` Dave Jones 2002-01-02 21:28 ` Christian Koenig 3 siblings, 2 replies; 185+ messages in thread From: Alan Cox @ 2002-01-02 20:59 UTC (permalink / raw) To: esr; +Cc: Linux Kernel List > Is there any way to safely probe a PCI motherboard to determine whether > or not it has ISA cards present, or ISA card slots? You can make an educated guess. However it is at best an educated guess. The DMI tables will tell you what PCI and ISA slots are present (but tend to be unreliable on older boxes). You can also look for an ISA bridge in lspci as a second source of information. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:59 ` Alan Cox @ 2002-01-02 20:46 ` Eric S. Raymond 2002-01-02 21:13 ` Dave Jones ` (3 more replies) 2002-01-02 21:00 ` Dave Jones 1 sibling, 4 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 20:46 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel List Alan Cox <alan@lxorguk.ukuu.org.uk>: > You can make an educated guess. However it is at best an educated guess. > The DMI tables will tell you what PCI and ISA slots are present (but ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > tend to be unreliable on older boxes). You can also look for an ISA bridge > in lspci as a second source of information. That sounds like it might be what I'm after. My goal is to be able to probe the machine and set ISA_CARDS based on the probe. What's a DMI table and how can I query it for the presence of ISA slots? What I want to do with this is make ISA-card questions invisible on modern PCI-only motherboards. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:46 ` Eric S. Raymond @ 2002-01-02 21:13 ` Dave Jones 2002-01-02 21:19 ` Alan Cox ` (2 subsequent siblings) 3 siblings, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-02 21:13 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > That sounds like it might be what I'm after. My goal is to be able to probe > the machine and set ISA_CARDS based on the probe. What's a DMI table and > how can I query it for the presence of ISA slots? http://people.redhat.com/arjanv/dmidecode.c -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:46 ` Eric S. Raymond 2002-01-02 21:13 ` Dave Jones @ 2002-01-02 21:19 ` Alan Cox 2002-01-02 21:04 ` Eric S. Raymond 2002-01-03 8:44 ` Eric W. Biederman 2002-01-03 12:46 ` Horst von Brand 3 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-02 21:19 UTC (permalink / raw) To: esr; +Cc: Alan Cox, Linux Kernel List > the machine and set ISA_CARDS based on the probe. What's a DMI table and > how can I query it for the presence of ISA slots? RTFG ;) > What I want to do with this is make ISA-card questions invisible on modern > PCI-only motherboards. For the smart config I assume not in general ? ftp://ftp.linux.org.uk/pub/linux/alan has a GPL DMI scanning app and library Alan ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:19 ` Alan Cox @ 2002-01-02 21:04 ` Eric S. Raymond 2002-01-02 22:34 ` Alan Cox 2002-01-03 9:26 ` Vojtech Pavlik 0 siblings, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 21:04 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel List Alan Cox <alan@lxorguk.ukuu.org.uk>: > > the machine and set ISA_CARDS based on the probe. What's a DMI table and > > how can I query it for the presence of ISA slots? > > RTFG ;) Umm...RTF*G*? Sorry...can't parse. :-) > > What I want to do with this is make ISA-card questions invisible on modern > > PCI-only motherboards. > > For the smart config I assume not in general ? Right. I'm well along on an autoconfigurator that can use the CML2 rulebase to do things like freezing to N all the symbols for PCI devices not explicitly found by autoprobe. > ftp://ftp.linux.org.uk/pub/linux/alan has a GPL DMI scanning app and library Which directory is it? Nothing has "dmi" in the name. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein, in H. Eves Return to Mathematical Circles, Boston: Prindle, Weber and Schmidt, 1988. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:04 ` Eric S. Raymond @ 2002-01-02 22:34 ` Alan Cox 2002-01-03 9:26 ` Vojtech Pavlik 1 sibling, 0 replies; 185+ messages in thread From: Alan Cox @ 2002-01-02 22:34 UTC (permalink / raw) To: esr; +Cc: Alan Cox, Linux Kernel List > Umm...RTF*G*? Sorry...can't parse. :-) [Google] > > ftp://ftp.linux.org.uk/pub/linux/alan has a GPL DMI scanning app and library > > Which directory is it? Nothing has "dmi" in the name. Its in the DMI directory. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:04 ` Eric S. Raymond 2002-01-02 22:34 ` Alan Cox @ 2002-01-03 9:26 ` Vojtech Pavlik 1 sibling, 0 replies; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-03 9:26 UTC (permalink / raw) To: Eric S. Raymond, Alan Cox, Linux Kernel List On Wed, Jan 02, 2002 at 04:04:49PM -0500, Eric S. Raymond wrote: > > > What I want to do with this is make ISA-card questions invisible on modern > > > PCI-only motherboards. > > > > For the smart config I assume not in general ? > > Right. I'm well along on an autoconfigurator that can use the CML2 rulebase > to do things like freezing to N all the symbols for PCI devices not explicitly > found by autoprobe. Just note that a board without ISA slots can still have ISA devices onboard, namely soundchips, and you still will want ISA drivers for those. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:46 ` Eric S. Raymond 2002-01-02 21:13 ` Dave Jones 2002-01-02 21:19 ` Alan Cox @ 2002-01-03 8:44 ` Eric W. Biederman 2002-01-03 12:46 ` Horst von Brand 3 siblings, 0 replies; 185+ messages in thread From: Eric W. Biederman @ 2002-01-03 8:44 UTC (permalink / raw) To: esr; +Cc: Alan Cox, Linux Kernel List "Eric S. Raymond" <esr@thyrsus.com> writes: > Alan Cox <alan@lxorguk.ukuu.org.uk>: > > You can make an educated guess. However it is at best an educated guess. > > The DMI tables will tell you what PCI and ISA slots are present (but > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > tend to be unreliable on older boxes). You can also look for an ISA bridge > > in lspci as a second source of information. > > That sounds like it might be what I'm after. My goal is to be able to probe > the machine and set ISA_CARDS based on the probe. What's a DMI table and > how can I query it for the presence of ISA slots? > > What I want to do with this is make ISA-card questions invisible on modern > PCI-only motherboards. Auto configuration only works for some variety of Plug-and-Play hardware. By that I mean that between a combination of the firmware and the hardware you can detect what is there. Plug-and-Play does not work reliably on ISA. Since PCI has been Plug-and-Play from the start it works well. I would suggest you assume that for any hardware that isn't present you assume it isn't there. For those things where auto detection is not reliable have a menu that let's you manually select the which pieces you actually want to worry about sounds reasonable. Say: Unprobeable hardware support ISA cards i2c devices lpc devices etc etc. With the kernel moving to support more and more hardware and things like lm-sensors showing up. Even the absence of slots does not mean that there aren't pieces that software can not get adequate information to setup correctly. As for DMI and it's ilk. The only sane thing I can see to do is have something that will report the motherboard id. (DMI does seem to do that fairly reiliably, as do MP tables). And then you build a database based on motherboard id upon the capabilities of the various motherboards. Looking up the datasheets from the various manufacturers should not be to hard of a job.. Plus it is a technique that can work on things other than stock PC's. Eric ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:46 ` Eric S. Raymond ` (2 preceding siblings ...) 2002-01-03 8:44 ` Eric W. Biederman @ 2002-01-03 12:46 ` Horst von Brand 2002-01-04 15:04 ` Kai Henningsen 3 siblings, 1 reply; 185+ messages in thread From: Horst von Brand @ 2002-01-03 12:46 UTC (permalink / raw) To: Eric S. Raymond, Linux Kernel List "Eric S. Raymond" <esr@thyrsus.com> said: [...] > What I want to do with this is make ISA-card questions invisible on modern > PCI-only motherboards. ... in order to make it impossible to build kernels for the coffepot in the corner on my shiny new machine. No, thanks. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:46 ` Horst von Brand @ 2002-01-04 15:04 ` Kai Henningsen 0 siblings, 0 replies; 185+ messages in thread From: Kai Henningsen @ 2002-01-04 15:04 UTC (permalink / raw) To: linux-kernel vonbrand@inf.utfsm.cl (Horst von Brand) wrote on 03.01.02 in <200201031246.g03Ckwkl021028@pincoya.inf.utfsm.cl>: > "Eric S. Raymond" <esr@thyrsus.com> said: > > [...] > > > What I want to do with this is make ISA-card questions invisible on modern > > PCI-only motherboards. > > ... in order to make it impossible to build kernels for the coffepot in the > corner on my shiny new machine. No, thanks. If you want to build the coffeepot kernel with the autoprobe result from your shiny new machine, you'll deserve whatever you get. That's just stupid. Either autoprobe on the right machine, or not at all. MfG Kai ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:59 ` Alan Cox 2002-01-02 20:46 ` Eric S. Raymond @ 2002-01-02 21:00 ` Dave Jones 2002-01-02 21:23 ` Bill Nottingham 1 sibling, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-02 21:00 UTC (permalink / raw) To: Alan Cox; +Cc: esr, Linux Kernel List On Wed, 2 Jan 2002, Alan Cox wrote: > You can make an educated guess. However it is at best an educated guess. > The DMI tables will tell you what PCI and ISA slots are present (but > tend to be unreliable on older boxes). And newer ones. I've seen 'Full length ISA slot' reported on a laptop for eg. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:00 ` Dave Jones @ 2002-01-02 21:23 ` Bill Nottingham 2002-01-02 21:13 ` Eric S. Raymond 2002-01-02 21:22 ` Dave Jones 0 siblings, 2 replies; 185+ messages in thread From: Bill Nottingham @ 2002-01-02 21:23 UTC (permalink / raw) To: Dave Jones; +Cc: Alan Cox, esr, Linux Kernel List Dave Jones (davej@suse.de) said: > > You can make an educated guess. However it is at best an educated guess. > > The DMI tables will tell you what PCI and ISA slots are present (but > > tend to be unreliable on older boxes). > > And newer ones. I've seen 'Full length ISA slot' reported on a laptop > for eg. I have an ia64 here that, according to dmidecode, has a 32bit NUBUS slot in it. AFAIK, that's not the case. ;) Bill ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:23 ` Bill Nottingham @ 2002-01-02 21:13 ` Eric S. Raymond 2002-01-02 21:31 ` Dave Jones 2002-01-02 21:22 ` Dave Jones 1 sibling, 1 reply; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 21:13 UTC (permalink / raw) To: Dave Jones, Alan Cox, Linux Kernel List Bill Nottingham <notting@redhat.com>: > Dave Jones (davej@suse.de) said: > > > You can make an educated guess. However it is at best an educated guess. > > > The DMI tables will tell you what PCI and ISA slots are present (but > > > tend to be unreliable on older boxes). > > > > And newer ones. I've seen 'Full length ISA slot' reported on a laptop > > for eg. > > I have an ia64 here that, according to dmidecode, has a > 32bit NUBUS slot in it. AFAIK, that's not the case. ;) I just downloaded and tested Arjan deVen's dmidecode.c program. That will do what I want, but it has the irritating problem that it requires root privileges for access to /dev/kmem. Is the DMI data available in /proc files anywhere? If not, should it be? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "Taking my gun away because I might shoot someone is like cutting my tongue out because I might yell `Fire!' in a crowded theater." -- Peter Venetoklis ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:13 ` Eric S. Raymond @ 2002-01-02 21:31 ` Dave Jones 2002-01-02 21:30 ` Eric S. Raymond 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-02 21:31 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > I just downloaded and tested Arjan deVen's dmidecode.c program. > That will do what I want, but it has the irritating problem that > it requires root privileges for access to /dev/kmem. Yup, needs to map BIOS tables. > Is the DMI data available in /proc files anywhere? Nope. > If not, should it be? Questionable. Dumping this in /proc just to make kernel autoconfig easier seems dreadful overkill. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:31 ` Dave Jones @ 2002-01-02 21:30 ` Eric S. Raymond 2002-01-02 21:48 ` Dave Jones 2002-01-02 22:08 ` Alan Cox 0 siblings, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 21:30 UTC (permalink / raw) To: Dave Jones; +Cc: Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > Questionable. Dumping this in /proc just to make kernel autoconfig > easier seems dreadful overkill. Actually, that's far from the only reason I can think of for including it. Consider the lives of people administering large server farms or clusters. Their hardware is not necessarily homogenous, and the ability to query the DMI tables on the fly could be useful both for administration and automatic process migration. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The right to buy weapons is the right to be free. -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:30 ` Eric S. Raymond @ 2002-01-02 21:48 ` Dave Jones 2002-01-02 21:47 ` Eric S. Raymond 2002-01-02 21:59 ` Mike Castle 2002-01-02 22:08 ` Alan Cox 1 sibling, 2 replies; 185+ messages in thread From: Dave Jones @ 2002-01-02 21:48 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > Consider the lives of people administering large server farms or clusters. > Their hardware is not necessarily homogenous, and the ability to query the DMI > tables on the fly could be useful both for administration and automatic > process migration. Given that 'dmidecode' works fine in those circumstances, that's still not a convincing argument imo. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:48 ` Dave Jones @ 2002-01-02 21:47 ` Eric S. Raymond 2002-01-02 22:12 ` Dave Jones 2002-01-03 13:00 ` Horst von Brand 2002-01-02 21:59 ` Mike Castle 1 sibling, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 21:47 UTC (permalink / raw) To: Dave Jones; +Cc: Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > > Consider the lives of people administering large server farms or > > clusters. Their hardware is not necessarily homogenous, and the > > ability to query the DMI tables on the fly could be useful both > > for administration and automatic process migration. > > Given that 'dmidecode' works fine in those circumstances, that's still > not a convincing argument imo. But only for people and programs with root privileges. It all turns then, on whether we want to insist that all software doing hardware probing must have root privileges to function. I submit that the answer is "no" -- the right direction, for security and other reasons, is to make *fewer* capabilities dependent on root privileges rather than more, and to reject design approaches that imply creating more suid programs to give ordinary users capabilities that involve only *reading* config information. There is already stuff in /proc that seems to be there for precisely this reason. So /proc/dmi would hardly be a violation of norms. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein, in H. Eves Return to Mathematical Circles, Boston: Prindle, Weber and Schmidt, 1988. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:47 ` Eric S. Raymond @ 2002-01-02 22:12 ` Dave Jones 2002-01-02 22:08 ` Eric S. Raymond 2002-01-03 13:00 ` Horst von Brand 1 sibling, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-02 22:12 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > > > Consider the lives of people administering large server farms or ^^^^^^^^^^^^^^^^^^^^ > > > clusters. Their hardware is not necessarily homogenous, and the > > > ability to query the DMI tables on the fly could be useful both > > > for administration and automatic process migration. > > Given that 'dmidecode' works fine in those circumstances, that's still > > not a convincing argument imo. > But only for people and programs with root privileges. ^^^^^^ Someone building a new kernel for a box (ie administrator) will have root priveledges. Though running 'make guessconfig' or whatever as root would suck. What Alan suggests (ripping the necessary bits out of dmidecode and making a setuid program) sounds better, as long as someone audits it afterwards. > then, on whether we want to insist that all software doing hardware > probing must have root privileges to function. probing isa isn't pretty. which is why we don't have anything as nice as /proc/bus/pci. The pnpbios support goes a little towards this, but only detects PNP cards obviously. Ye olde ISA is all but invisible to /proc As we get the devicefs in 2.5 fleshed out, hopefully such things will come in time for the older busses like PNPISA & EISA > There is already stuff in /proc that seems to be there for precisely this > reason. So /proc/dmi would hardly be a violation of norms. Just because its a shitbucket, doesn't mean we should keep adding to it. It's become the dumping ground for so much crap that just doesn't need to be there. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:12 ` Dave Jones @ 2002-01-02 22:08 ` Eric S. Raymond 2002-01-02 22:39 ` Alan Cox ` (2 more replies) 0 siblings, 3 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 22:08 UTC (permalink / raw) To: Dave Jones; +Cc: Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > Someone building a new kernel for a box (ie administrator) will have > root priveledges. Though running 'make guessconfig' or whatever as > root would suck. Yeah, that's my point. Saying "just make it suid" is not a good answer, because it ignores the fact that smart sysdamins don't want to run suid programs more than absolutely necessary. Not to mention screwing people who follow Linus's good advice and configure/build kernels as non-root. > > There is already stuff in /proc that seems to be there for precisely this > > reason. So /proc/dmi would hardly be a violation of norms. > > Just because its a shitbucket, doesn't mean we should keep adding to it. > It's become the dumping ground for so much crap that just doesn't need to > be there. But this is not a bad reason. Allowing people to avoid running suid programs is a *good* reason. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:08 ` Eric S. Raymond @ 2002-01-02 22:39 ` Alan Cox 2002-01-02 22:24 ` Eric S. Raymond 2002-01-02 22:46 ` Lionel Bouton 2002-01-05 6:56 ` H. Peter Anvin 2 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-02 22:39 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Alan Cox, Linux Kernel List > Yeah, that's my point. Saying "just make it suid" is not a good answer, > because it ignores the fact that smart sysdamins don't want to run suid > programs more than absolutely necessary. Not to mention screwing people > who follow Linus's good advice and configure/build kernels as non-root. So you want the lowest possible priviledge level. Because if so thats setuid app not kernel space. Arguing about the same code in either kernel space verus setuid app space is garbage. Alan ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:39 ` Alan Cox @ 2002-01-02 22:24 ` Eric S. Raymond 2002-01-02 22:50 ` Alan Cox ` (3 more replies) 0 siblings, 4 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 22:24 UTC (permalink / raw) To: Alan Cox; +Cc: Dave Jones, Linux Kernel List Alan Cox <alan@lxorguk.ukuu.org.uk>: > So you want the lowest possible priviledge level. Because if so thats > setuid app not kernel space. Arguing about the same code in either kernel > space verus setuid app space is garbage. But you're thinking like a developer, not a user. The right question is which approach requires the lowest level of *user* privilege to get the job done. Comparing world-readable /proc files versus a setuid app, the answer is obvious. This sort of thing is exactly what /proc is *for*. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:24 ` Eric S. Raymond @ 2002-01-02 22:50 ` Alan Cox 2002-01-02 22:34 ` Eric S. Raymond 2002-01-02 22:53 ` Mike Castle ` (2 subsequent siblings) 3 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-02 22:50 UTC (permalink / raw) To: esr; +Cc: Alan Cox, Dave Jones, Linux Kernel List > But you're thinking like a developer, not a user. The right question > is which approach requires the lowest level of *user* privilege to get > the job done. Comparing world-readable /proc files versus a setuid app, > the answer is obvious. This sort of thing is exactly what /proc is *for*. Both require the same level of user privilege. cat /proc/wasteofmemory/dmi | dmidecoder v /sbin/dmidump | dmidecoder ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:50 ` Alan Cox @ 2002-01-02 22:34 ` Eric S. Raymond 2002-01-02 23:09 ` Alan Cox 2002-01-03 13:10 ` Horst von Brand 0 siblings, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 22:34 UTC (permalink / raw) To: Alan Cox; +Cc: Dave Jones, Linux Kernel List Alan Cox <alan@lxorguk.ukuu.org.uk>: > > But you're thinking like a developer, not a user. The right question > > is which approach requires the lowest level of *user* privilege to get > > the job done. Comparing world-readable /proc files versus a setuid app, > > the answer is obvious. This sort of thing is exactly what /proc is *for*. > > Both require the same level of user privilege. > > cat /proc/wasteofmemory/dmi | dmidecoder > v > /sbin/dmidump | dmidecoder What? Perhaps we're talking at cross-prorposes here. What I'm proposing is that /proc/dmi should be a world-readable /proc file with the property that cat /proc/dmi gives you a DMI report. No root privileges or SUID programs needed. Surely that would be an improvement on having to run Arjan's dmidecode as root or requiring it to be SUID. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> No one who's seen it in action can say the phrase "government help" without either laughing or crying. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:34 ` Eric S. Raymond @ 2002-01-02 23:09 ` Alan Cox 2002-01-02 23:09 ` Eric S. Raymond 2002-01-03 13:10 ` Horst von Brand 1 sibling, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-02 23:09 UTC (permalink / raw) To: esr; +Cc: Alan Cox, Dave Jones, Linux Kernel List > What? Perhaps we're talking at cross-prorposes here. What I'm proposing > is that /proc/dmi should be a world-readable /proc file with the property > that > cat /proc/dmi > > gives you a DMI report. No root privileges or SUID programs needed. > Surely that would be an improvement on having to run Arjan's dmidecode as > root or requiring it to be SUID. Of course it isnt. cat /proc/dmi executes kernel mode code which is totally priviledged. /sbin/dmidecode executes slightly priviledged code which will core dump not crash the box if it misparses the mapped table. Also you might want to restrict or lie about DMI access. It may include serial numbers or other info considered private. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:09 ` Alan Cox @ 2002-01-02 23:09 ` Eric S. Raymond 2002-01-02 23:52 ` Alan Cox 2002-01-02 23:56 ` Mike Castle 0 siblings, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 23:09 UTC (permalink / raw) To: Alan Cox; +Cc: Dave Jones, Linux Kernel List Alan Cox <alan@lxorguk.ukuu.org.uk>: > Of course it isnt. cat /proc/dmi executes kernel mode code which is totally > priviledged. /sbin/dmidecode executes slightly priviledged code which will > core dump not crash the box if it misparses the mapped table. You're thinking inside-out again. Sigh...user privileges. *User* privileges! -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:09 ` Eric S. Raymond @ 2002-01-02 23:52 ` Alan Cox 2002-01-02 23:56 ` Mike Castle 1 sibling, 0 replies; 185+ messages in thread From: Alan Cox @ 2002-01-02 23:52 UTC (permalink / raw) To: esr; +Cc: Alan Cox, Dave Jones, Linux Kernel List > > priviledged. /sbin/dmidecode executes slightly priviledged code which will > > core dump not crash the box if it misparses the mapped table. > > You're thinking inside-out again. Sigh...user privileges. *User* privileges! Its simple. If the sysadmin has decided the user can see the DMI data (which is itself an open question since if you have the serial number you can often use that alone to do really *irritating* things to university/workplace IT people you don't like [1]. Alan [1] like getting vendors to turn up and take it away because its "faulty" ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:09 ` Eric S. Raymond 2002-01-02 23:52 ` Alan Cox @ 2002-01-02 23:56 ` Mike Castle 2002-01-03 0:00 ` Dave Jones 1 sibling, 1 reply; 185+ messages in thread From: Mike Castle @ 2002-01-02 23:56 UTC (permalink / raw) To: Linux Kernel List; +Cc: Eric S. Raymond, Alan Cox, Dave Jones On Wed, Jan 02, 2002 at 06:09:26PM -0500, Eric S. Raymond wrote: > Alan Cox <alan@lxorguk.ukuu.org.uk>: > > Of course it isnt. cat /proc/dmi executes kernel mode code which is totally > > priviledged. /sbin/dmidecode executes slightly priviledged code which will I hope you at least recomment /usr/sbin/dmidecode. Least I hope that isn't necessary for booting. ;-> > > core dump not crash the box if it misparses the mapped table. > > You're thinking inside-out again. Sigh...user privileges. *User* privileges! It's not just a simple od -c type of output that a post-processor could decode turn back into binary and decode. The routine would still have to locate the DMI table, and decode at least the appropriate length of the table, present that to the output, and then dump the output in hex format or something. Why risk getting that wrong and screwing up kernel internals when it can already be done in userspace? mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:56 ` Mike Castle @ 2002-01-03 0:00 ` Dave Jones 2002-01-03 0:37 ` Mike Castle 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-03 0:00 UTC (permalink / raw) To: Mike Castle; +Cc: Linux Kernel List, Eric S. Raymond, Alan Cox On Wed, 2 Jan 2002, Mike Castle wrote: > It's not just a simple od -c type of output that a post-processor could > decode turn back into binary and decode. The routine would still have to > locate the DMI table, and decode at least the appropriate length of the > table, present that to the output, and then dump the output in hex format > or something. Why risk getting that wrong and screwing up kernel internals > when it can already be done in userspace? And as I've already pointed out twice it isn't a bullet proof solution to use DMI anyway in this circumstance. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 0:00 ` Dave Jones @ 2002-01-03 0:37 ` Mike Castle 2002-01-03 0:58 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Mike Castle @ 2002-01-03 0:37 UTC (permalink / raw) To: Linux Kernel List On Thu, Jan 03, 2002 at 01:00:23AM +0100, Dave Jones wrote: > And as I've already pointed out twice it isn't a bullet proof solution to > use DMI anyway in this circumstance. I never got the impression that DMI was going to be the exclusive way of obtaining information, but rather, as a supplement. For example, currently loaded and functioning drivers may also be analyzed in a variety of ways. I seem to remember this being described as a goal for CML2 back when ESR first started talking about it, but I can't find appropriate posts anywhere (kinda vague thing to look for :-). And this kind of stuff was discussed than as well. Either that or I'm completely mis-remembering. mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 0:37 ` Mike Castle @ 2002-01-03 0:58 ` Dave Jones 2002-01-03 13:35 ` Horst von Brand 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-03 0:58 UTC (permalink / raw) To: Mike Castle; +Cc: Linux Kernel List On Wed, 2 Jan 2002, Mike Castle wrote: > I never got the impression that DMI was going to be the exclusive way of > obtaining information, but rather, as a supplement. In this case though, it's not just bad, it's exceptionally bad. Taking the 5 boxes I currently have powered up as test cases.. Old quad ppro - Wierd compaq thing, no DMI tables. So won't do a thing here. Athlon (one of the original ones), no ISA slots - Correct DMI tables. Vaio laptop - Reports what is probably its PCMCIA slot as an ISA slot Cyrix III box, no ISA slots - Reports 4 slots present K6 box, with ISA slots - Reports none. 1 in 5 gets it right. Are the odds really worth the hassle just to keep Aunt Tillie happy ? -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 0:58 ` Dave Jones @ 2002-01-03 13:35 ` Horst von Brand 2002-01-03 13:46 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Horst von Brand @ 2002-01-03 13:35 UTC (permalink / raw) To: Dave Jones; +Cc: Linux Kernel List Dave Jones <davej@suse.de> said: > On Wed, 2 Jan 2002, Mike Castle wrote: > > I never got the impression that DMI was going to be the exclusive way of > > obtaining information, but rather, as a supplement. > > In this case though, it's not just bad, it's exceptionally bad. > > Taking the 5 boxes I currently have powered up as test cases.. > > Old quad ppro > - Wierd compaq thing, no DMI tables. So won't do a thing here. > > Athlon (one of the original ones), no ISA slots > - Correct DMI tables. > > Vaio laptop > - Reports what is probably its PCMCIA slot as an ISA slot > > Cyrix III box, no ISA slots > - Reports 4 slots present > > K6 box, with ISA slots > - Reports none. > > 1 in 5 gets it right. Are the odds really worth the hassle > just to keep Aunt Tillie happy ? I'd wagger Aunt Tillie doesn't run Linux on Ye Olde Coffepot, but on a new, PCI-only machine. So this is doubly silly... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 13:35 ` Horst von Brand @ 2002-01-03 13:46 ` Dave Jones 2002-01-03 16:42 ` Horst von Brand 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-03 13:46 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel List On Thu, 3 Jan 2002, Horst von Brand wrote: > I'd wagger Aunt Tillie doesn't run Linux on Ye Olde Coffepot, but on a new, > PCI-only machine. So this is doubly silly... *your* Aunt Tillie perhaps. I know several folks whose parents have now inherited their offsprings old computers, and are now using Linux on them to read their mail, write a book, whatever.. And these cast offs are not fantastic machines, they're 486/586 class. Fleeting judgements like yours above are just plain wrong. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 13:46 ` Dave Jones @ 2002-01-03 16:42 ` Horst von Brand 2002-01-03 18:06 ` Alex 0 siblings, 1 reply; 185+ messages in thread From: Horst von Brand @ 2002-01-03 16:42 UTC (permalink / raw) To: Dave Jones; +Cc: Linux Kernel List Dave Jones <davej@suse.de> said: > On Thu, 3 Jan 2002, Horst von Brand wrote: > > I'd wagger Aunt Tillie doesn't run Linux on Ye Olde Coffepot, but on a new, > > PCI-only machine. So this is doubly silly... > > *your* Aunt Tillie perhaps. I know several folks whose parents have > now inherited their offsprings old computers, and are now using Linux > on them to read their mail, write a book, whatever.. > And these cast offs are not fantastic machines, they're 486/586 class. If I give the old coffepot to Aunt Tillie with Linux, I'll take some care of the updates and such for her later. And for sanity's sake I'll stick to distribution-build kernels if at all possible in any case. > Fleeting judgements like yours above are just plain wrong. Right. But for Aunt Tillie who has to do the managing of the machine by herself, she'll either go to a distribution and won't fool around with compiling 2.4.18preX for the sake of it, or is at least mildly interested in kernel development and doesn't need handholding. Why an average (non-hacker) Aunt Tillie won't be satisfied with e.g. Red Hat or Madrake or whatever kernel or an update is just way beyond me. Source-build kernels are strictly "check out this new feature" or "see if it breaks", or perhaps "need a custom configuration for this piece of junk from the scrapheap" not for day-to-day use by unwashed masses. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 16:42 ` Horst von Brand @ 2002-01-03 18:06 ` Alex 2002-01-03 18:16 ` Horst von Brand ` (3 more replies) 0 siblings, 4 replies; 185+ messages in thread From: Alex @ 2002-01-03 18:06 UTC (permalink / raw) To: Horst von Brand; +Cc: Dave Jones, Linux Kernel List > Why an average > (non-hacker) Aunt Tillie won't be satisfied with e.g. Red Hat or Madrake or > whatever kernel or an update is just way beyond me. Okay then lemme try to give you a reallife case... I *can* compile the kernel perfectly alright, but let's face it, it can easily end up as a medieval pain in the ***. The 2.2.20+reiserfs patch that I managed to compile didnt swallow the reiserfs that my Suse7.3 linux actually installed already. Well that's beyond ISA in this case but then here we have a lot of old ISA-ethernetcards, for example, that I'd just simply like to work properly.... Let's face the bare fact : Linux life could be *way* more comfortable... This stupid Win2k or even *brrr* XP ^H^H^H detects all the hardware fine when installing. Even ISA. So should Linux. My 0.02c Alex ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 18:06 ` Alex @ 2002-01-03 18:16 ` Horst von Brand 2002-01-03 18:22 ` Patrick Mochel ` (2 subsequent siblings) 3 siblings, 0 replies; 185+ messages in thread From: Horst von Brand @ 2002-01-03 18:16 UTC (permalink / raw) To: Alex; +Cc: Linux Kernel List Alex <mail_ker@xarch.tu-graz.ac.at> said: [...] > Let's face the bare fact : Linux life could be *way* more comfortable... > This stupid Win2k or even *brrr* XP ^H^H^H detects all the hardware > fine when installing. Even ISA. So should Linux. Yep. Like Linux getting the 3rd IDE on my ISA SB16 as a matter of course, which WinNT claims doesn't exist. Like having to get a huge "driver" onto WinNT for using a parallel Zip drive, which just works out of the box with Linux. Or my notebook's (Win98se) network card driver, which hangs the machine on boot if no network connection. Don't get me started on "easy installation" and "autodetects everything" with Windows. Oh, wait. You are a troll, right? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 18:06 ` Alex 2002-01-03 18:16 ` Horst von Brand @ 2002-01-03 18:22 ` Patrick Mochel 2002-01-03 22:26 ` Alan Cox 2002-01-03 18:41 ` Gábor Lénárt 2002-01-07 21:56 ` Mark H. Wood 3 siblings, 1 reply; 185+ messages in thread From: Patrick Mochel @ 2002-01-03 18:22 UTC (permalink / raw) To: Alex; +Cc: Horst von Brand, Dave Jones, Linux Kernel List > Let's face the bare fact : Linux life could be *way* more comfortable... > This stupid Win2k or even *brrr* XP ^H^H^H detects all the hardware > fine when installing. Even ISA. So should Linux. I don't believe that Win2k does it (it's not from the PnP family, is it?). But, I don't doubt that XP does it on contemporary hardware. It requires ACPI support in the BIOS. And, ACPI enumerates all of the legacy devices in the system. So, we're still relying on the firmware to tell us what's there. One of the points of this thread, and many others, is that you can't rely on it. Every BIOS is buggy. Personally, I like the idea of dumping the firmware tables (DMI, ACPI, etc) during early init, then letting a userspace program telling the kernel what is there based on what the firmware says. If we know a particular table in a particular BIOS is bad, we can ignore it or work around it. The auto-config tool can use either what the kernel knows (as exported to userland), or it can use some parsing tool to parse the tables (with the same intelligence to know which tables are borked). And, don't forget that most Windows OSes punt on some hardware. That's why there's the nice "Add New Hardware" wizard... -pat ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 18:22 ` Patrick Mochel @ 2002-01-03 22:26 ` Alan Cox 2002-01-03 22:20 ` Patrick Mochel 0 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-03 22:26 UTC (permalink / raw) To: Patrick Mochel; +Cc: Alex, Horst von Brand, Dave Jones, Linux Kernel List > I don't believe that Win2k does it (it's not from the PnP family, is it?). > But, I don't doubt that XP does it on contemporary hardware. It requires > ACPI support in the BIOS. And, ACPI enumerates all of the legacy devices > in the system. PnPBIOS also enumerates the legacy hardware that can be known about (ie is soldered down) Alan ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 22:26 ` Alan Cox @ 2002-01-03 22:20 ` Patrick Mochel 2002-01-03 22:31 ` Alan Cox 0 siblings, 1 reply; 185+ messages in thread From: Patrick Mochel @ 2002-01-03 22:20 UTC (permalink / raw) To: Alan Cox; +Cc: Alex, Horst von Brand, Dave Jones, Linux Kernel List On Thu, 3 Jan 2002, Alan Cox wrote: > > I don't believe that Win2k does it (it's not from the PnP family, is it?). > > But, I don't doubt that XP does it on contemporary hardware. It requires > > ACPI support in the BIOS. And, ACPI enumerates all of the legacy devices > > in the system. > > PnPBIOS also enumerates the legacy hardware that can be known about (ie > is soldered down) How do you derive that information? Some table, right? (Sorry, I haven't RTFS yet). -pat ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 22:20 ` Patrick Mochel @ 2002-01-03 22:31 ` Alan Cox 0 siblings, 0 replies; 185+ messages in thread From: Alan Cox @ 2002-01-03 22:31 UTC (permalink / raw) To: Patrick Mochel Cc: Alan Cox, Alex, Horst von Brand, Dave Jones, Linux Kernel List > > PnPBIOS also enumerates the legacy hardware that can be known about (ie > > is soldered down) > > How do you derive that information? Some table, right? (Sorry, I haven't > RTFS yet). You make BIOS32 calls ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 18:06 ` Alex 2002-01-03 18:16 ` Horst von Brand 2002-01-03 18:22 ` Patrick Mochel @ 2002-01-03 18:41 ` Gábor Lénárt 2002-01-03 22:24 ` Alan Cox 2002-01-07 21:56 ` Mark H. Wood 3 siblings, 1 reply; 185+ messages in thread From: Gábor Lénárt @ 2002-01-03 18:41 UTC (permalink / raw) To: Alex; +Cc: linux-kernel On Thu, Jan 03, 2002 at 07:06:38PM +0100, Alex wrote: > Okay then lemme try to give you a reallife case... I *can* compile the > kernel perfectly alright, but let's face it, it can easily end up as a > medieval pain in the ***. The 2.2.20+reiserfs patch that I managed to > compile didnt swallow the reiserfs that my Suse7.3 linux actually > installed already. Well that's beyond ISA in this case but then here we > have a lot of old ISA-ethernetcards, for example, that I'd just simply > like to work properly.... > > Let's face the bare fact : Linux life could be *way* more comfortable... > This stupid Win2k or even *brrr* XP ^H^H^H detects all the hardware > fine when installing. Even ISA. So should Linux. A big no-no, IMHO. Linux is a UNIX like system. I like Linux, I like UNIX. And I want my UNIX to ONLY do what I would like. If I say that there's an SB Live, and compile&install ALSA/OSS/whatever for sound card, it's right. If my OS want to do it without any request by me it's wrong! Hey this is not a child-toy, it's Linux. IMHO. - Gabor ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 18:41 ` Gábor Lénárt @ 2002-01-03 22:24 ` Alan Cox 0 siblings, 0 replies; 185+ messages in thread From: Alan Cox @ 2002-01-03 22:24 UTC (permalink / raw) To: lgb; +Cc: Alex, linux-kernel > A big no-no, IMHO. Linux is a UNIX like system. I like Linux, I like UNIX. > And I want my UNIX to ONLY do what I would like. If I say that there's > an SB Live, and compile&install ALSA/OSS/whatever for sound card, it's right. > If my OS want to do it without any request by me it's wrong! Hey this is > not a child-toy, it's Linux. IMHO. So you configure your kernel and other people autoconfig their kernel. Not a problem ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 18:06 ` Alex ` (2 preceding siblings ...) 2002-01-03 18:41 ` Gábor Lénárt @ 2002-01-07 21:56 ` Mark H. Wood 3 siblings, 0 replies; 185+ messages in thread From: Mark H. Wood @ 2002-01-07 21:56 UTC (permalink / raw) Cc: Linux Kernel List On Thu, 3 Jan 2002, Alex wrote: [snippage] > This stupid Win2k or even *brrr* XP ^H^H^H detects all the hardware > fine when installing. Even ISA. So should Linux. It does it v e r y s l o w l y however. I've been following this thread primarily to see why it isn't faster. They seem to still use the old "throw all drivers at the box and see which ones stick" approach for everything, when one ought to at least be able to ask decent buses what's there and skip 70% of the stuff not needed in milliseconds. But non-PNP ISA gear is of course going to need the old probing or manual configuration. Apparently the BIOS can't be relied on to figure things out properly in quite a number of cases. Is it, in fact, ridiculous to think of just asking the bridge chip "do you see anything" (in cases where there *is* a bridge chip)? IOW how hard is it to just talk to the decent portion of the hardware and get useful answers? The most interesting question (for IBM-PC type boxes) is "is there any non-PNP ISA gear other than the standard serial, parallel, keyboard, mouse, etc. ports?" A reliable answer to that question eliminates probing in the "no" case: you can just ask the hardware what it is. These constraints bound a large and growing portion of the set of machines to be configured, and it might be useful to optimize for them if it isn't too costly. -- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Our lives are forever changed. But *that* is exactly as it always was. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:34 ` Eric S. Raymond 2002-01-02 23:09 ` Alan Cox @ 2002-01-03 13:10 ` Horst von Brand 1 sibling, 0 replies; 185+ messages in thread From: Horst von Brand @ 2002-01-03 13:10 UTC (permalink / raw) To: Eric S. Raymond, Linux Kernel List "Eric S. Raymond" <esr@thyrsus.com> said: [...] > What? Perhaps we're talking at cross-prorposes here. What I'm proposing > is that /proc/dmi should be a world-readable /proc file with the property > that > cat /proc/dmi > > gives you a DMI report. No root privileges or SUID programs needed. > Surely that would be an improvement on having to run Arjan's dmidecode as > root or requiring it to be SUID. You seem to assume that in-kernel code is automatically safe... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:24 ` Eric S. Raymond 2002-01-02 22:50 ` Alan Cox @ 2002-01-02 22:53 ` Mike Castle 2002-01-02 23:16 ` Alan Cox 2002-01-02 23:04 ` Lionel Bouton 2002-01-05 6:58 ` H. Peter Anvin 3 siblings, 1 reply; 185+ messages in thread From: Mike Castle @ 2002-01-02 22:53 UTC (permalink / raw) To: Linux Kernel List On Wed, Jan 02, 2002 at 05:24:48PM -0500, Eric S. Raymond wrote: > But you're thinking like a developer, not a user. The right question > is which approach requires the lowest level of *user* privilege to get > the job done. Comparing world-readable /proc files versus a setuid app, > the answer is obvious. This sort of thing is exactly what /proc is *for*. What's wrong with a startup routine that includes something like: dmidecode > /var/run/dmi mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:53 ` Mike Castle @ 2002-01-02 23:16 ` Alan Cox 2002-01-02 23:31 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-02 23:16 UTC (permalink / raw) To: dalgoda; +Cc: Linux Kernel List > What's wrong with a startup routine that includes something like: > > dmidecode > /var/run/dmi Absolutely nothing, and that also handily means it isnt setuid 8) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:16 ` Alan Cox @ 2002-01-02 23:31 ` Dave Jones 0 siblings, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-02 23:31 UTC (permalink / raw) To: Alan Cox; +Cc: dalgoda, Linux Kernel List On Wed, 2 Jan 2002, Alan Cox wrote: > > What's wrong with a startup routine that includes something like: > > dmidecode > /var/run/dmi > Absolutely nothing, and that also handily means it isnt setuid 8) Indeed, it's perfect. Except no distro does it (yet), but it's definitly the best idea so far in this thread. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:24 ` Eric S. Raymond 2002-01-02 22:50 ` Alan Cox 2002-01-02 22:53 ` Mike Castle @ 2002-01-02 23:04 ` Lionel Bouton 2002-01-03 3:49 ` Cameron Simpson 2002-01-05 6:58 ` H. Peter Anvin 3 siblings, 1 reply; 185+ messages in thread From: Lionel Bouton @ 2002-01-02 23:04 UTC (permalink / raw) To: Linux Kernel List; +Cc: Alan Cox, Dave Jones Eric S. Raymond wrote: > Alan Cox <alan@lxorguk.ukuu.org.uk>: > >>So you want the lowest possible priviledge level. Because if so thats >>setuid app not kernel space. Arguing about the same code in either kernel >>space verus setuid app space is garbage. >> > > But you're thinking like a developer, not a user. The right question > is which approach requires the lowest level of *user* privilege to get > the job done. Comparing world-readable /proc files versus a setuid app, > the answer is obvious. Reading proc files requires running kernel space code, do we have kernel space code running with *user* priviledge now? > This sort of thing is exactly what /proc is *for*. > Hum, "/proc" is only good for _flamewars_ on lklm ;-) LB. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:04 ` Lionel Bouton @ 2002-01-03 3:49 ` Cameron Simpson 2002-01-03 4:03 ` Dave Jones ` (3 more replies) 0 siblings, 4 replies; 185+ messages in thread From: Cameron Simpson @ 2002-01-03 3:49 UTC (permalink / raw) To: Lionel Bouton; +Cc: Linux Kernel List, Alan Cox, Dave Jones On Thu, Jan 03, 2002 at 12:04:57AM +0100, Lionel Bouton <Lionel.Bouton@free.fr> wrote: | Eric S. Raymond wrote: | > Alan Cox <alan@lxorguk.ukuu.org.uk>: | >>So you want the lowest possible priviledge level. Because if so thats | >>setuid app not kernel space. Arguing about the same code in either kernel | >>space verus setuid app space is garbage. | >> | > But you're thinking like a developer, not a user. The right question | > is which approach requires the lowest level of *user* privilege to get | > the job done. Comparing world-readable /proc files versus a setuid app, | > the answer is obvious. | | Reading proc files requires running kernel space code, do we have kernel | space code running with *user* priviledge now? Oh please don't inject (more) noise into this1 Doing ANYTHING involves running kerel space code somewhere. It is still possible to talk meaningfully about: - opening a publicly readable file in /proc to get some info, which will run some kernel code (which can presumably be trusted; if you don't trust your kernel you have a serious problem) versus - running a setuid binary (however audited) to get the info; said binary may have bugs, security holes, race conditions etc; it may be hacked post boot (no so easy to do to the live kernel image), etc Further, binaries which grovel in /dev/kmem tend to have to be kept in sync with the kernel; in-kernel code is fundamentally in sync. -- Cameron Simpson, DoD#743 cs@zip.com.au http://www.zip.com.au/~cs/ Although it does not mindfully keep guard, in the small mountain fields the scarecrow does not stand in vain. - trans. Bukkoku Kokushi ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:49 ` Cameron Simpson @ 2002-01-03 4:03 ` Dave Jones 2002-01-03 6:46 ` Mike Castle ` (2 subsequent siblings) 3 siblings, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-03 4:03 UTC (permalink / raw) To: Cameron Simpson; +Cc: Lionel Bouton, Linux Kernel List, Alan Cox On Thu, 3 Jan 2002, Cameron Simpson wrote: > Further, binaries which grovel in /dev/kmem tend to have to be kept in sync > with the kernel; in-kernel code is fundamentally in sync. dmidecode hasn't been updated since it was written, and still works fine. I could also name several other such tools that have never needed a change due to kernel upgrade, so this argument is bogus. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:49 ` Cameron Simpson 2002-01-03 4:03 ` Dave Jones @ 2002-01-03 6:46 ` Mike Castle 2002-01-03 12:35 ` Alan Cox 2002-01-03 21:15 ` Lionel Bouton 3 siblings, 0 replies; 185+ messages in thread From: Mike Castle @ 2002-01-03 6:46 UTC (permalink / raw) To: Linux Kernel List On Thu, Jan 03, 2002 at 02:49:04PM +1100, Cameron Simpson wrote: > - opening a publicly readable file in /proc to get some info, > which will run some kernel code (which can presumably be trusted; > if you don't trust your kernel you have a serious problem) Some unnecessary kernel code. Which, because it's unnecessary, won't necessarily be checked for correctness. > versus > > - running a setuid binary (however audited) to get the info; said > binary may have bugs, security holes, race conditions etc; it may be > hacked post boot (no so easy to do to the live kernel image), etc vs - running a single app as root upon boot. > Further, binaries which grovel in /dev/kmem tend to have to be kept in sync > with the kernel; in-kernel code is fundamentally in sync. Bull. There have been several drivers that simply can not compile because they are out of sync, in the 2.4 kernel mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:49 ` Cameron Simpson 2002-01-03 4:03 ` Dave Jones 2002-01-03 6:46 ` Mike Castle @ 2002-01-03 12:35 ` Alan Cox 2002-01-03 12:39 ` Vojtech Pavlik ` (2 more replies) 2002-01-03 21:15 ` Lionel Bouton 3 siblings, 3 replies; 185+ messages in thread From: Alan Cox @ 2002-01-03 12:35 UTC (permalink / raw) To: cs; +Cc: Lionel Bouton, Linux Kernel List, Alan Cox, Dave Jones > binary may have bugs, security holes, race conditions etc; it may be > hacked post boot (no so easy to do to the live kernel image), etc Just like the kernel, only the binary is a little less dangerous. Hacking live kernel images is trivial also btw. There are tools for it. > Further, binaries which grovel in /dev/kmem tend to have to be kept in sync > with the kernel; in-kernel code is fundamentally in sync. Disagree. Its reading BIOS tables not poking at kernel internals ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:35 ` Alan Cox @ 2002-01-03 12:39 ` Vojtech Pavlik 2002-01-05 7:03 ` H. Peter Anvin 2002-01-03 16:00 ` Cryto verification of Kernel against Trojan code?? Timothy Covell 2002-01-03 21:58 ` ISA slot detection on PCI systems? Cameron Simpson 2 siblings, 1 reply; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-03 12:39 UTC (permalink / raw) To: Alan Cox; +Cc: cs, Lionel Bouton, Linux Kernel List, Dave Jones On Thu, Jan 03, 2002 at 12:35:36PM +0000, Alan Cox wrote: > > Further, binaries which grovel in /dev/kmem tend to have to be kept in sync > > with the kernel; in-kernel code is fundamentally in sync. > > Disagree. Its reading BIOS tables not poking at kernel internals It's still not very nice for userspace apps to touch hardware directly, even if it's just BIOS memory ... -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:39 ` Vojtech Pavlik @ 2002-01-05 7:03 ` H. Peter Anvin 2002-01-05 17:16 ` Albert D. Cahalan 2002-01-06 21:03 ` Vojtech Pavlik 0 siblings, 2 replies; 185+ messages in thread From: H. Peter Anvin @ 2002-01-05 7:03 UTC (permalink / raw) To: linux-kernel Followup to: <20020103133912.B17280@suse.cz> By author: Vojtech Pavlik <vojtech@suse.cz> In newsgroup: linux.dev.kernel > > It's still not very nice for userspace apps to touch hardware directly, > even if it's just BIOS memory ... > Red herring. It's not very nice for *applications* to not indirect through a driver, but if that driver is in userspace or kernel space is irrelevant. Incidentally, "applications" here include a lot of the parsers that produce /proc output. /proc/pci is occationally handy, but it is also an example on why you shouldn't do data reduction in kernel space unless you can avoid it. Now /proc/bus/pci is available and contains all the data, however. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-05 7:03 ` H. Peter Anvin @ 2002-01-05 17:16 ` Albert D. Cahalan 2002-01-05 17:34 ` Dave Jones 2002-01-06 21:03 ` Vojtech Pavlik 1 sibling, 1 reply; 185+ messages in thread From: Albert D. Cahalan @ 2002-01-05 17:16 UTC (permalink / raw) To: H. Peter Anvin; +Cc: linux-kernel H. Peter Anvin writes: > Red herring. It's not very nice for *applications* to not indirect > through a driver, but if that driver is in userspace or kernel space > is irrelevant. Incidentally, "applications" here include a lot of the > parsers that produce /proc output. /proc/pci is occationally handy, > but it is also an example on why you shouldn't do data reduction in > kernel space unless you can avoid it. Now /proc/bus/pci is available > and contains all the data, however. Of course, /proc/bus/pci contains forbidden binary files. You're supposed to be happy with ASCII text, as found in the /proc/pci file. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-05 17:16 ` Albert D. Cahalan @ 2002-01-05 17:34 ` Dave Jones 2002-01-05 20:29 ` H. Peter Anvin 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-05 17:34 UTC (permalink / raw) To: Albert D. Cahalan; +Cc: H. Peter Anvin, linux-kernel On Sat, 5 Jan 2002, Albert D. Cahalan wrote: > Of course, /proc/bus/pci contains forbidden binary files. > You're supposed to be happy with ASCII text, as found in > the /proc/pci file. You miss the point. The point was that /proc/pci doesn't expose all of pci config space, whereas /proc/bus/pci does. The fact that it's binary instead of ascii is neither here nor there. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-05 17:34 ` Dave Jones @ 2002-01-05 20:29 ` H. Peter Anvin 2002-01-06 1:19 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: H. Peter Anvin @ 2002-01-05 20:29 UTC (permalink / raw) To: Dave Jones; +Cc: Albert D. Cahalan, linux-kernel Dave Jones wrote: > On Sat, 5 Jan 2002, Albert D. Cahalan wrote: > > >>Of course, /proc/bus/pci contains forbidden binary files. >>You're supposed to be happy with ASCII text, as found in >>the /proc/pci file. >> > > You miss the point. The point was that /proc/pci doesn't > expose all of pci config space, whereas /proc/bus/pci does. > The fact that it's binary instead of ascii is neither here nor there. > ... and if you want to see something that's worse than either, check out /proc/ide/hda/identify. Converting binary to hex doesn't aid in display in any shape, way, or form; all it does is make it impossible to use "dd" to do what I want, or from using my own hexdump tool. Binary has a place, and "ASCII for ASCIIs sake" is just stupidity. -hpa ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-05 20:29 ` H. Peter Anvin @ 2002-01-06 1:19 ` Dave Jones 2002-01-06 12:19 ` Mr. James W. Laferriere 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-06 1:19 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Albert D. Cahalan, linux-kernel On Sat, 5 Jan 2002, H. Peter Anvin wrote: > ... and if you want to see something that's worse than either, check out > /proc/ide/hda/identify. AFAIAC, the /proc/ide/ stuff should never have happened. It's proven that every bit of it can be done in userspace. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-06 1:19 ` Dave Jones @ 2002-01-06 12:19 ` Mr. James W. Laferriere 2002-01-06 13:16 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Mr. James W. Laferriere @ 2002-01-06 12:19 UTC (permalink / raw) To: Dave Jones; +Cc: H. Peter Anvin, Albert D. Cahalan, linux-kernel Hello Dave , All , On Sun, 6 Jan 2002, Dave Jones wrote: > On Sat, 5 Jan 2002, H. Peter Anvin wrote: > > > ... and if you want to see something that's worse than either, check out > > /proc/ide/hda/identify. > AFAIAC, the /proc/ide/ stuff should never have happened. > It's proven that every bit of it can be done in userspace. Then lets get rid of /proc/scsi , How about /proc/sys ... What is the differance here ? Maybe I am missing something ? Hoping for enlightenment . JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-06 12:19 ` Mr. James W. Laferriere @ 2002-01-06 13:16 ` Dave Jones 2002-01-06 15:26 ` Mr. James W. Laferriere 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-06 13:16 UTC (permalink / raw) To: Mr. James W. Laferriere; +Cc: H. Peter Anvin, Albert D. Cahalan, linux-kernel On Sun, 6 Jan 2002, Mr. James W. Laferriere wrote: > > AFAIAC, the /proc/ide/ stuff should never have happened. > > It's proven that every bit of it can be done in userspace. > Then lets get rid of /proc/scsi , How about /proc/sys ... > What is the differance here ? Maybe I am missing something ? And what would you replace /proc/scsi/ with ? Neither of the two you mention have viable alternatives. (yet) The only time I'd consider sysctl(2) over poking /proc/sys entries would possibly be on an embedded system with no /proc/sys. And even then, I'd rather try and justify having /proc. ISTR viro proposing to split proc/sys out to sysctlfs at some point, which would solve this dilemma nicely. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-06 13:16 ` Dave Jones @ 2002-01-06 15:26 ` Mr. James W. Laferriere 2002-01-06 18:20 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Mr. James W. Laferriere @ 2002-01-06 15:26 UTC (permalink / raw) To: Dave Jones; +Cc: Linux Kernel Maillist Hello Dave , All, On Sun, 6 Jan 2002, Dave Jones wrote: > On Sun, 6 Jan 2002, Mr. James W. Laferriere wrote: > > > AFAIAC, the /proc/ide/ stuff should never have happened. > > > It's proven that every bit of it can be done in userspace. > > Then lets get rid of /proc/scsi , How about /proc/sys ... > > What is the differance here ? Maybe I am missing something ? > And what would you replace /proc/scsi/ with ? And what is there to replace /proc/ide ? I see no other facility in /proc to do the job . Again am I missing something here ? > Neither of the two you mention have viable alternatives. (yet) Then I submit that neither does ide . I see nothing in your reply that shows me a differance between ide & scsi in /proc . > The only time I'd consider sysctl(2) over poking /proc/sys entries > would possibly be on an embedded system with no /proc/sys. And even then, > I'd rather try and justify having /proc. ISTR viro proposing to split > proc/sys out to sysctlfs at some point, which would solve this dilemma > nicely. Now tho I have to agree with you here . Tia , JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-06 15:26 ` Mr. James W. Laferriere @ 2002-01-06 18:20 ` Dave Jones 2002-01-07 13:35 ` Mr. James W. Laferriere 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-06 18:20 UTC (permalink / raw) To: Mr. James W. Laferriere; +Cc: Linux Kernel Maillist On Sun, 6 Jan 2002, Mr. James W. Laferriere wrote: > And what is there to replace /proc/ide ? I see no other facility > in /proc to do the job . Again am I missing something here ? 99% of everything done by /proc/ide/ can be done in userspace by parsing /proc/bus/pci. The remaining 1% can be done with ioctls. The info exposed by /proc/scsi may be exposed by ioctls also, (in which case, that too can be done entirely in userspace), however, I'm not sure everything shown there is accessable by means other than proc parsing. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-06 18:20 ` Dave Jones @ 2002-01-07 13:35 ` Mr. James W. Laferriere 0 siblings, 0 replies; 185+ messages in thread From: Mr. James W. Laferriere @ 2002-01-07 13:35 UTC (permalink / raw) To: Dave Jones; +Cc: Linux Kernel Maillist Hello Dave , On Sun, 6 Jan 2002, Dave Jones wrote: > On Sun, 6 Jan 2002, Mr. James W. Laferriere wrote: > > And what is there to replace /proc/ide ? I see no other facility > > in /proc to do the job . Again am I missing something here ? > 99% of everything done by /proc/ide/ can be done in userspace by parsing > /proc/bus/pci. The remaining 1% can be done with ioctls. Hmm , I see there is some info in ide . But I don't see it as being very setable . OK , I am beginning to see what you are speaking of . ide looks like it wasn't completed to me . > The info exposed by /proc/scsi may be exposed by ioctls also, (in which > case, that too can be done entirely in userspace), however, I'm not sure > everything shown there is accessable by means other than proc parsing. Not sure either , And I am sure you would have more idea than I . I like scsi's completeness & setability . Thank you for filling me in . JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-05 7:03 ` H. Peter Anvin 2002-01-05 17:16 ` Albert D. Cahalan @ 2002-01-06 21:03 ` Vojtech Pavlik 2002-01-06 22:16 ` Alan Cox 1 sibling, 1 reply; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-06 21:03 UTC (permalink / raw) To: H. Peter Anvin; +Cc: linux-kernel On Fri, Jan 04, 2002 at 11:03:24PM -0800, H. Peter Anvin wrote: > > It's still not very nice for userspace apps to touch hardware directly, > > even if it's just BIOS memory ... > > > > Red herring. It's not very nice for *applications* to not indirect > through a driver, but if that driver is in userspace or kernel space > is irrelevant. Incidentally, "applications" here include a lot of the > parsers that produce /proc output. /proc/pci is occationally handy, > but it is also an example on why you shouldn't do data reduction in > kernel space unless you can avoid it. Now /proc/bus/pci is available > and contains all the data, however. I don't propose having human-readable output of DMI data in /proc, just the binary data much like /proc/bus/pci has. That isn't much bloat in kernel, and is a clearly defined interface, unlike reading /dev/kmem. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-06 21:03 ` Vojtech Pavlik @ 2002-01-06 22:16 ` Alan Cox 2002-01-07 7:42 ` Vojtech Pavlik 0 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-06 22:16 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: H. Peter Anvin, linux-kernel > I don't propose having human-readable output of DMI data in /proc, just > the binary data much like /proc/bus/pci has. That isn't much bloat in > kernel, and is a clearly defined interface, unlike reading /dev/kmem. kmem is a cleanly defined interface ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-06 22:16 ` Alan Cox @ 2002-01-07 7:42 ` Vojtech Pavlik 0 siblings, 0 replies; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-07 7:42 UTC (permalink / raw) To: Alan Cox; +Cc: H. Peter Anvin, linux-kernel On Sun, Jan 06, 2002 at 10:16:53PM +0000, Alan Cox wrote: > > I don't propose having human-readable output of DMI data in /proc, just > > the binary data much like /proc/bus/pci has. That isn't much bloat in > > kernel, and is a clearly defined interface, unlike reading /dev/kmem. > > kmem is a cleanly defined interface For reading the memory contents, not for searching for BIOS data. Anyway, I see this discussion doesn't lead anywhere, so I guess I'd better just stop. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Cryto verification of Kernel against Trojan code?? 2002-01-03 12:35 ` Alan Cox 2002-01-03 12:39 ` Vojtech Pavlik @ 2002-01-03 16:00 ` Timothy Covell 2002-01-03 21:58 ` ISA slot detection on PCI systems? Cameron Simpson 2 siblings, 0 replies; 185+ messages in thread From: Timothy Covell @ 2002-01-03 16:00 UTC (permalink / raw) To: Alan Cox, cs; +Cc: Lionel Bouton, Linux Kernel List, Alan Cox, Dave Jones On Thursday 03 January 2002 06:35, Alan Cox wrote: > > binary may have bugs, security holes, race conditions etc; it may be > > hacked post boot (no so easy to do to the live kernel image), etc > > Just like the kernel, only the binary is a little less dangerous. Hacking > live kernel images is trivial also btw. There are tools for it. And that brings me to my crazy thought for the day. System.map is what is says, a map of the system. Would it make any sense to compute an md5 hash on it and use it as a means of verifying that the kernel is clean from tampering? (That's assuming that the hackers didn't replace syscalls with a trojan with exactly the same size and same location.) -- timothy.covell@ashavan.org. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:35 ` Alan Cox 2002-01-03 12:39 ` Vojtech Pavlik 2002-01-03 16:00 ` Cryto verification of Kernel against Trojan code?? Timothy Covell @ 2002-01-03 21:58 ` Cameron Simpson 2 siblings, 0 replies; 185+ messages in thread From: Cameron Simpson @ 2002-01-03 21:58 UTC (permalink / raw) To: Alan Cox; +Cc: Lionel Bouton, Linux Kernel List, Dave Jones On Thu, Jan 03, 2002 at 12:35:36PM +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: | > Further, binaries which grovel in /dev/kmem tend to have to be kept in sync | > with the kernel; in-kernel code is fundamentally in sync. | Disagree. Its reading BIOS tables not poking at kernel internals I'll pay this one. Assuming the BIOS is always (in some guarrenteed hw related sense) in the same place in kmem. -- Cameron Simpson, DoD#743 cs@zip.com.au http://www.zip.com.au/~cs/ The question of whether computers can think is just like the question of whether submarines can swim. - Edsger W. Dijkstra ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:49 ` Cameron Simpson ` (2 preceding siblings ...) 2002-01-03 12:35 ` Alan Cox @ 2002-01-03 21:15 ` Lionel Bouton 2002-01-03 21:26 ` Dave Jones 3 siblings, 1 reply; 185+ messages in thread From: Lionel Bouton @ 2002-01-03 21:15 UTC (permalink / raw) To: cs, Linux Kernel List I made a stupid post elsewhere in this thread and recognised it. But here I'm far from convinced I should have shut my big mouth :-p Cameron Simpson wrote: > [...] > | Reading proc files requires running kernel space code, do we have kernel > | space code running with *user* priviledge now? > > Oh please don't inject (more) noise into this1 Doing ANYTHING involves > running kerel space code somewhere. Nothing to do with my point. You can't make usefull code without kernel syscalls sure but you don't need kernel code for most of your code. We speak of code priviledge here. If you put the whole dmidecode in kernel space you make it running at full system level priviledge. So there's little difference (and in fact favorable to suid solution) to the priviledge level of the running code. Point. Anyway this thread branch is dead, we didn't understand Eric's point which was on the level of priviledge the *user* using the code needs. > It is still possible to talk > meaningfully about: > > - opening a publicly readable file in /proc to get some info, > which will run some kernel code (which can presumably be trusted; > if you don't trust your kernel you have a serious problem) I have different levels of trusting. For example I trust code I've read and understood (somehow did program proof) as much as I trust my capability to understand the code. So in short I don't fully trust anything but have more confidence in some things (experience running it, heard good things from people I *trust*, ...). > versus > > - running a setuid binary (however audited) to get the info; said > binary may have bugs, security holes, race conditions etc; These aren't things kernel code is immune to. > it may be > hacked post boot (no so easy to do to the live kernel image), etc > Hacked post boot <- security bug outside of dmidecode. If security is of concern this bug should be corrected with or without existance of an user-level dmidecode. You mean probability of bug greater out-of-kernel than in-kernel ? I don't deal with such things as bug probabilities on corner cases like this, sorry. If you have enough security bugs in a corner case of reading (not even writing to) /dev/kmem (BIOS tables, not kernel data) to make probabilities I don't trust your systems :-p > Further, binaries which grovel in /dev/kmem tend to have to be kept in sync > with the kernel; Read dmidecode.c, it's an exception. > in-kernel code is fundamentally in sync. > Wrong, history shows there are always parts of the kernel behind. LB. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 21:15 ` Lionel Bouton @ 2002-01-03 21:26 ` Dave Jones 0 siblings, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-03 21:26 UTC (permalink / raw) To: Lionel Bouton; +Cc: cs, Linux Kernel List On Thu, 3 Jan 2002, Lionel Bouton wrote: > > Further, binaries which grovel in /dev/kmem tend to have to be kept in sync > > with the kernel; > Read dmidecode.c, it's an exception. Not really. acpidmp, dump_pirq, sbf, mgainfo.. the list goes on. The original statement above is nonsense. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:24 ` Eric S. Raymond ` (2 preceding siblings ...) 2002-01-02 23:04 ` Lionel Bouton @ 2002-01-05 6:58 ` H. Peter Anvin 3 siblings, 0 replies; 185+ messages in thread From: H. Peter Anvin @ 2002-01-05 6:58 UTC (permalink / raw) To: linux-kernel Followup to: <20020102172448.A18153@thyrsus.com> By author: "Eric S. Raymond" <esr@thyrsus.com> In newsgroup: linux.dev.kernel > > But you're thinking like a developer, not a user. The right question > is which approach requires the lowest level of *user* privilege to get > the job done. Comparing world-readable /proc files versus a setuid app, > the answer is obvious. This sort of thing is exactly what /proc is *for*. > BULLSHIT. The user privilege level is identical in either case (no special privilege needed.) The setuid app is a lower privilege level than the kernel code you're proposing adding. Not just is it bloat, it's actually a deterioration in the overall security of the system. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:08 ` Eric S. Raymond 2002-01-02 22:39 ` Alan Cox @ 2002-01-02 22:46 ` Lionel Bouton 2002-01-02 22:51 ` Dave Jones 2002-01-05 6:56 ` H. Peter Anvin 2 siblings, 1 reply; 185+ messages in thread From: Lionel Bouton @ 2002-01-02 22:46 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Alan Cox, Linux Kernel List Eric S. Raymond wrote: > [...] > > But this is not a bad reason. Allowing people to avoid running suid > programs is a *good* reason. > Usually yes. But for a code that simply parses /dev/kmem content without taking args... Just took a quick look at dmidecode.c and auditing this code doesn't seem out of reach. What's the difference security-wise between running this code in kernel space and in a suid prog? Avoiding loading libraries? Frankly I don't see the point. LB. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:46 ` Lionel Bouton @ 2002-01-02 22:51 ` Dave Jones 2002-01-02 22:48 ` Eric S. Raymond 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-02 22:51 UTC (permalink / raw) To: Lionel Bouton; +Cc: esr, Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Lionel Bouton wrote: > > But this is not a bad reason. Allowing people to avoid running suid > > programs is a *good* reason. > Usually yes. But for a code that simply parses /dev/kmem content without > taking args... > Just took a quick look at dmidecode.c and auditing this code doesn't > seem out of reach. Exactly. And 90% of it can be ditched. > What's the difference security-wise between running this code in kernel > space and in a suid prog? Avoiding loading libraries? > Frankly I don't see the point. *shrug* about the same point as having a /proc/acpi/dsdt I'd guess. (Which worked fine as a run-as-root program called acpidmp, but for some reason someone thought it'd be good to dump in /proc) -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:51 ` Dave Jones @ 2002-01-02 22:48 ` Eric S. Raymond 2002-01-02 23:10 ` Dave Jones ` (4 more replies) 0 siblings, 5 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 22:48 UTC (permalink / raw) To: Dave Jones; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > > Just took a quick look at dmidecode.c and auditing this code doesn't > > seem out of reach. > > Exactly. And 90% of it can be ditched. But a setuid program *will not solve my problem*. The person running the autoconfigurator is not and should not be doing so as root. Requiring the person to stop and sun sudo just so the autoconfigurator can proceed is exactly the sort of pointless obstacle we should *not* be putting in front of users! (Telling me to rely on dmidecode already being installed SUID is not a good answer either. No prizes for figuring out why.) Ay caramba...please guys, try get your heads out of the internals and start thinking from the *useability* angle for once! -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "The power to tax involves the power to destroy;...the power to destroy may defeat and render useless the power to create...." -- Chief Justice John Marshall, 1819. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:48 ` Eric S. Raymond @ 2002-01-02 23:10 ` Dave Jones 2002-01-03 2:10 ` Eric S. Raymond ` (3 more replies) 2002-01-02 23:15 ` Alan Cox ` (3 subsequent siblings) 4 siblings, 4 replies; 185+ messages in thread From: Dave Jones @ 2002-01-02 23:10 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > > > Just took a quick look at dmidecode.c and auditing this code doesn't > > > seem out of reach. > > Exactly. And 90% of it can be ditched. > But a setuid program *will not solve my problem*. Given decoding DMI isn't going to get you 100% fool proof way of detecting slots (See posts on laptops/other usually-with-crap-bios hardware), I think you're barking up the wrong tree with this anyway. And if you don't know what hardware you've got in the box your configuring a kernel for, its questionable that you should be doing so in the first place. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:10 ` Dave Jones @ 2002-01-03 2:10 ` Eric S. Raymond 2002-01-03 2:44 ` Dave Jones 2002-01-03 14:12 ` Horst von Brand 2002-01-03 3:07 ` Greg Hennessy ` (2 subsequent siblings) 3 siblings, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 2:10 UTC (permalink / raw) To: Dave Jones; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > Given decoding DMI isn't going to get you 100% fool proof way of > detecting slots (See posts on laptops/other usually-with-crap-bios > hardware), I think you're barking up the wrong tree with this > anyway. But at the least I could have logic that says: if you get a DMI readout and there are no ISA slots listed, *then* do useful deductions. > And if you don't know what hardware you've got in the box your > configuring a kernel for, its questionable that you should be > doing so in the first place. That's exactly the bad assumption we need to dynamite. Vaporize. Nuke. It should be possible to build a correctly customized kernel without opening the case of your machine. It should be possible for non-technical people to customize kernels. Kernel customization should present an interface based on what you want to *do* with the machine, not the specific hardware inside it (because the configurator is smart enough to map from the intended-function domain to the hardware- specifics domain). Think useability. On Macintoshes, you configure a kernel by moving the equivalents of modules in and out of a system folder. Users tune their kernels by moving files around -- no muttering of elaborate incantations required. *That's* the direction we should be moving in; there is no good technical reason for the process to be anywhere near as arcane as it is now. I have spent eighteen months thinking very hard about this problem, and whacking a significant piece of it with actual code. So I can say this: the reason linux kernel configuration is still a black art is *only* that lots of people *want it to be that way*. We have elected to treat kernel-building as an initiatory rite that separates the worthy geeks from the unwashed technopeasant masses. This is fine if all we want is to impress each other with our wizardliness. If, on the other hand, we are serious about world domination, it's an attitude that's got to go. We have enough real technical problems to solve without surrounding Linux with a thicket of pseudo-problems. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> During waves of terror attacks, Israel's national police chief will call on all concealed-handgun permit holders to make sure they carry firearms at all times, and Israelis have many examples where concealed permit holders have saved lives. -- John R. Lott Conservatism is the blind and fear-filled worship of dead radicals. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 2:10 ` Eric S. Raymond @ 2002-01-03 2:44 ` Dave Jones 2002-01-03 3:03 ` Eric S. Raymond ` (2 more replies) 2002-01-03 14:12 ` Horst von Brand 1 sibling, 3 replies; 185+ messages in thread From: Dave Jones @ 2002-01-03 2:44 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > > hardware), I think you're barking up the wrong tree with this > > anyway. > But at the least I could have logic that says: if you get a DMI > readout and there are no ISA slots listed, *then* do useful deductions. See other posting with examples of dramatic failures of 'slots in box, but dmi says none' and 'no slots, dmi says some'. still think this is usable ? You're nuts. > This is fine if all we want is to impress each other with our wizardliness. > If, on the other hand, we are serious about world domination, it's an > attitude that's got to go. We have enough real technical problems to solve > without surrounding Linux with a thicket of pseudo-problems. You're solving a non-problem. Some examples of target audience you're aiming for in your previous mail were I believe.. o The geek next door who wants to tinker and learn about the kernel. Said geek is going to learn a damn sight more currently than he will with a dumbed down pointy clicky "build me a kernel" button. o Aunt Tilley. Vendors already ship an array of kernels which should make it unnecessary for her to have to build a kernel. If you still think world domination is going to appear by idiotproofing the kernel build process, I think you're in for a surprise. We have far bigger usability problems in userspace. The point is that $newcomertolinux doesn't need to know what a kernel is, let alone have to build one. They just see "Booting progress" "Log in" "Desktop". -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 2:44 ` Dave Jones @ 2002-01-03 3:03 ` Eric S. Raymond 2002-01-03 3:26 ` Dave Jones ` (3 more replies) 2002-01-03 5:30 ` Andrew Morton 2002-01-03 9:14 ` David Woodhouse 2 siblings, 4 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 3:03 UTC (permalink / raw) To: Dave Jones; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > See other posting with examples of dramatic failures of > 'slots in box, but dmi says none' and 'no slots, dmi says some'. > still think this is usable ? You're nuts. One of my background assumptions is that the older a machine is, the more likely it is that the person doing the config will have a clue about what they're doing. These days hardware is so cheap that only geeks try to cram Linux onto old systems -- and even the geeks mostly do it just to prove they can. Thus I'm not very worried about DMI read failing on older hardware. My main objective is to make configuration painless on modern PCI-only hardware -- which is why I want to be able to tell when there are no ISA slots, so I can deep-six questions about ISA drivers. > You're solving a non-problem. > Some examples of target audience you're aiming for in your previous > mail were I believe.. > > o The geek next door who wants to tinker and learn about the kernel. > Said geek is going to learn a damn sight more currently than he will > with a dumbed down pointy clicky "build me a kernel" button. Your "they must show willingness to suffer pain, otherwise they're not worthy" attitude is really showing here. I'm not proposing that the "dumbed-down" version be the only version, but that the kernel and the config tools make "build me a kernel at the push of a button *possible* for those who don't want to go any deeper. > o Aunt Tilley. > Vendors already ship an array of kernels which should make it > unnecessary for her to have to build a kernel. Yes. But *I* want Aunt Tilley to be able to download the latest kernel sources and build/install them herself, without ever feeling that the task is beyond her capabilities. Part of the reason I want this is for the capability itself; partly I want it pour encourager les autres -- to demonstrate, by tackling one of the toughest cases, that much of the complexity and anti-useability of Linux is an artificial and unnecessary creation of the culture that created it, rather than a result of actual technical depth of the problem. I believe we need to learn the discipline of useability and take it seriously. Because talk plus code is much more convincing than just talk, I'm trying to demonstrate this by coding. But I'll talk about it too :-). > If you still think world domination is going to appear by idiotproofing > the kernel build process, I think you're in for a surprise. > We have far bigger usability problems in userspace. The point is that > $newcomertolinux doesn't need to know what a kernel is, let alone > have to build one. They just see "Booting progress" "Log in" "Desktop". Sure we have bigger idiotproofing problems. But this is the one that (a) my skillset is well matched to, and (b) no one else is worrying about. World domination will happen, if it happens, because lots of people are willing to obsess about useability issues at *all* levels of the system. Including this one. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Don't ever think you know what's right for the other person. He might start thinking he knows what's right for you. -- Paul Williams, `Das Energi' ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:03 ` Eric S. Raymond @ 2002-01-03 3:26 ` Dave Jones 2002-01-03 3:18 ` Eric S. Raymond 2002-01-03 3:34 ` Brian Gerst ` (2 subsequent siblings) 3 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-03 3:26 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > One of my background assumptions is that the older a machine is, the > more likely it is that the person doing the config will have a clue about > what they're doing. Bzzzzt. See Greg Hennessy's post. (Not that I'm implying he hasn't a clue, but he makes a good point) > These days hardware is so cheap that only geeks try to cram Linux onto > old systems Bzzzzzt. Linux is getting deployed in lots of small businesses running mailservers/firewalls etc on old P90's and the likes. Not because they're run by geeks, but because they're running on a low budget. > Thus I'm not very worried about DMI read failing on older hardware. It fails on newer hardware too. The Vaio I quoted is less than a year old. The CyrixIII BIOS is less than 6 months old. > My main objective is to make configuration painless on modern PCI-only > hardware -- which is why I want to be able to tell when there are no > ISA slots, so I can deep-six questions about ISA drivers. Go down the DMI path, and get it right _sometimes_, or take a zero. Getting it right sometimes is likely to do more harm than good. > > o The geek next door who wants to tinker and learn about the kernel. > > Said geek is going to learn a damn sight more currently than he will > > with a dumbed down pointy clicky "build me a kernel" button. > > Your "they must show willingness to suffer pain, otherwise they're not worthy" > attitude is really showing here. Crap. I'm implying that there should be a learning curve to everything no matter how small it may be. You're trying to remove the curve altogether. > Yes. But *I* want Aunt Tilley to be able to download the latest kernel > sources and build/install them herself, without ever feeling that the task > is beyond her capabilities. *shakes head*, ok I'm all done trying to argue this one. > I believe we need to learn the discipline of useability and take it seriously. > Because talk plus code is much more convincing than just talk, I'm trying > to demonstrate this by coding. But I'll talk about it too :-). And write a book perchance ? SCNR 8-) -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:26 ` Dave Jones @ 2002-01-03 3:18 ` Eric S. Raymond 2002-01-03 3:36 ` Brian Gerst 2002-01-03 3:39 ` Dave Jones 0 siblings, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 3:18 UTC (permalink / raw) To: Dave Jones; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > Go down the DMI path, and get it right _sometimes_, or take a zero. > Getting it right sometimes is likely to do more harm than good. Not in this case. If the DMI read fails, the worst-case result is the user sees some ISA extra questions. > Crap. I'm implying that there should be a learning curve to everything > no matter how small it may be. You're trying to remove the curve > altogether. Damn straight. Not that I think that's necessarily 100% achievable, but it's the right way to aim. > And write a book perchance ? SCNR 8-) It's happened before... :-) -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> No kingdom can be secured otherwise than by arming the people. The possession of arms is the distinction between a freeman and a slave. -- "Political Disquisitions", a British republican tract of 1774-1775 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:18 ` Eric S. Raymond @ 2002-01-03 3:36 ` Brian Gerst 2002-01-03 3:35 ` Eric S. Raymond 2002-01-03 3:39 ` Dave Jones 1 sibling, 1 reply; 185+ messages in thread From: Brian Gerst @ 2002-01-03 3:36 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List "Eric S. Raymond" wrote: > > Dave Jones <davej@suse.de>: > > Go down the DMI path, and get it right _sometimes_, or take a zero. > > Getting it right sometimes is likely to do more harm than good. > > Not in this case. If the DMI read fails, the worst-case result is the > user sees some ISA extra questions. No, the worst case is if the DMI read says no ISA slots when there really are some, and the user misses a driver that he needs. -- Brian Gerst ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:36 ` Brian Gerst @ 2002-01-03 3:35 ` Eric S. Raymond 2002-01-03 4:15 ` Brian Gerst 0 siblings, 1 reply; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 3:35 UTC (permalink / raw) To: Brian Gerst; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List Brian Gerst <bgerst@didntduck.org>: > > Not in this case. If the DMI read fails, the worst-case result is the > > user sees some ISA extra questions. > > No, the worst case is if the DMI read says no ISA slots when there > really are some, and the user misses a driver that he needs. Nobody has told me this is a real failure case yet. To cause a problem, the situation would have to be that DMI read fails to detect a card in use in an ISA slot. It's OK if it reports no slots when all slots are empty. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The possession of arms by the people is the ultimate warrant that government governs only with the consent of the governed. -- Jeff Snyder ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:35 ` Eric S. Raymond @ 2002-01-03 4:15 ` Brian Gerst 2002-01-03 4:15 ` Eric S. Raymond 0 siblings, 1 reply; 185+ messages in thread From: Brian Gerst @ 2002-01-03 4:15 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List [-- Attachment #1: Type: text/plain, Size: 741 bytes --] "Eric S. Raymond" wrote: > > Brian Gerst <bgerst@didntduck.org>: > > > Not in this case. If the DMI read fails, the worst-case result is the > > > user sees some ISA extra questions. > > > > No, the worst case is if the DMI read says no ISA slots when there > > really are some, and the user misses a driver that he needs. > > Nobody has told me this is a real failure case yet. To cause a problem, > the situation would have to be that DMI read fails to detect a card in > use in an ISA slot. It's OK if it reports no slots when all slots are > empty. Well, I just popped in an old 3com 509TP network card (non-PnP) into my main box and dmidecode still failed to show the single ISA slot, only 4 PCI and 1 AGP. -- Brian Gerst [-- Attachment #2: dmi.out --] [-- Type: text/plain, Size: 5680 bytes --] SMBIOS 2.3 present. DMI 2.3 present. 26 structures occupying 1912 bytes. DMI table at 0x000F04F0. Handle 0x0000 DMI type 0, 20 bytes. BIOS Information Block Vendor: American Megatrends Inc. Version: 62710 Release: 07/15/97 BIOS base: 0xF0000 ROM size: 192K Capabilities: Flags: 0x000000007FCBDE90 Handle 0x0001 DMI type 1, 25 bytes. System Information Block Vendor: Product: Version: 0000000 Serial Number: Handle 0x0002 DMI type 2, 8 bytes. Board Information Block Vendor: FIC Product: SD11 Version: 1.x Serial Number: 00000000 Handle 0x0003 DMI type 3, 17 bytes. Chassis Information Block Vendor: Chassis Type: Desktop Version: 1.0 Serial Number: 0000000 Asset Tag: Handle 0x0004 DMI type 4, 32 bytes. Processor Socket Designation: Slot-A Processor Type: Central Processor Processor Family: K5 Family Processor Manufacturer: AMD Processor Version: Athlon(tm) Handle 0x0005 DMI type 7, 19 bytes. Cache Socket: L1 Cache L1 Internal Cache: write-back L1 Cache Size: 128K L1 Cache Maximum: 128K L1 Cache Type: Synchronous Handle 0x0006 DMI type 7, 19 bytes. Cache Socket: L2 Cache L2 Internal Cache: write-back L2 Cache Size: 8192K L2 Cache Maximum: 512K L2 Cache Type: Synchronous Handle 0x0007 DMI type 5, 22 bytes. Memory Controller Handle 0x0008 DMI type 6, 12 bytes. Memory Bank Socket: DIMM1 Banks: 0 1 Speed: 15nS Type: Installed Size: 128Mbyte (Double sided) Enabled Size: 128Mbyte (Double sided) Handle 0x0009 DMI type 6, 12 bytes. Memory Bank Socket: DIMM2 Banks: 2 3 Speed: 15nS Type: Installed Size: 256Mbyte (Double sided) Enabled Size: 256Mbyte (Double sided) Handle 0x000A DMI type 6, 12 bytes. Memory Bank Socket: DIMM3 Banks: 4 5 Speed: 15nS Type: Installed Size: 128Mbyte (Double sided) Enabled Size: 128Mbyte (Double sided) Handle 0x000B DMI type 9, 13 bytes. Card Slot Slot: PCI1 Type: 32bit PCI Status: Available. Slot Features: 3.3v Shared Handle 0x000C DMI type 9, 13 bytes. Card Slot Slot: PCI2 Type: 32bit PCI Status: In use. Slot Features: 3.3v Shared Handle 0x000D DMI type 9, 13 bytes. Card Slot Slot: PCI3 Type: 32bit PCI Status: Available. Slot Features: 3.3v Shared Handle 0x000E DMI type 9, 13 bytes. Card Slot Slot: PCI4 Type: 32bit PCI Status: In use. Slot Features: 3.3v Shared Handle 0x000F DMI type 9, 13 bytes. Card Slot Slot: AGP Type: 32bit AGP 4x Status: In use. Slot Features: 3.3v Shared Handle 0x0010 DMI type 8, 9 bytes. Port Connector Internal Designator: COM Port Internal Connector Type: None External Designator: Serial Port A External Connector Type: DB-9 pin male Port Type: Serial Port 16650A Compatible Handle 0x0011 DMI type 8, 9 bytes. Port Connector Internal Designator: COM Port Internal Connector Type: None External Designator: Serial Port B External Connector Type: DB-9 pin male Port Type: Serial Port 16650A Compatible Handle 0x0012 DMI type 8, 9 bytes. Port Connector Internal Designator: LPT Port Internal Connector Type: None External Designator: Parallel Port External Connector Type: DB-25 pin female Port Type: Parallel Port ECP/EPP Handle 0x0013 DMI type 8, 9 bytes. Port Connector Internal Designator: Keyboard Internal Connector Type: None External Designator: Keyboard External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x0014 DMI type 8, 9 bytes. Port Connector Internal Designator: Mouse Internal Connector Type: None External Designator: PS/2 Mouse External Connector Type: PS/2 Port Type: Mouse Port Handle 0x0015 DMI type 8, 9 bytes. Port Connector Internal Designator: Floppy Internal Connector Type: On Board Floppy External Designator: Floppy External Connector Type: None Port Type: None Handle 0x0016 DMI type 8, 9 bytes. Port Connector Internal Designator: Primary IDE Internal Connector Type: On Board IDE External Designator: IDE-1 External Connector Type: None Port Type: None Handle 0x0017 DMI type 8, 9 bytes. Port Connector Internal Designator: Secondary IDE Internal Connector Type: On Board IDE External Designator: IDE-2 External Connector Type: None Port Type: None Handle 0x0018 DMI type 8, 9 bytes. Port Connector Internal Designator: USB Port Internal Connector Type: None External Designator: USB External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0019 DMI type 13, 22 bytes. BIOS Language Information ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 4:15 ` Brian Gerst @ 2002-01-03 4:15 ` Eric S. Raymond 2002-01-03 4:27 ` Brian Gerst 0 siblings, 1 reply; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 4:15 UTC (permalink / raw) To: Brian Gerst; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List Brian Gerst <bgerst@didntduck.org>: > > Nobody has told me this is a real failure case yet. To cause a problem, > > the situation would have to be that DMI read fails to detect a card in > > use in an ISA slot. It's OK if it reports no slots when all slots are > > empty. > > Well, I just popped in an old 3com 509TP network card (non-PnP) into my > main box and dmidecode still failed to show the single ISA slot, only 4 > PCI and 1 AGP. I realize this may sound like a dumb question...but are sure the card works and is not just an inert mass o' silicon? I have couple of 3c509s knocking around here myself and I'm not at all sure they're alive. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The day will come when the mystical generation of Jesus by the Supreme Being as his father, in the womb of a virgin, will be classed with the fable of the generation of Minerva in the brain of Jupiter. -- Thomas Jefferson, 1823 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 4:15 ` Eric S. Raymond @ 2002-01-03 4:27 ` Brian Gerst 2002-01-03 4:30 ` Eric S. Raymond 0 siblings, 1 reply; 185+ messages in thread From: Brian Gerst @ 2002-01-03 4:27 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List "Eric S. Raymond" wrote: > > Brian Gerst <bgerst@didntduck.org>: > > > Nobody has told me this is a real failure case yet. To cause a problem, > > > the situation would have to be that DMI read fails to detect a card in > > > use in an ISA slot. It's OK if it reports no slots when all slots are > > > empty. > > > > Well, I just popped in an old 3com 509TP network card (non-PnP) into my > > main box and dmidecode still failed to show the single ISA slot, only 4 > > PCI and 1 AGP. > > I realize this may sound like a dumb question...but are sure the card works > and is not just an inert mass o' silicon? I have couple of 3c509s knocking > around here myself and I'm not at all sure they're alive. Yes, it worked. -- Brian Gerst ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 4:27 ` Brian Gerst @ 2002-01-03 4:30 ` Eric S. Raymond 0 siblings, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 4:30 UTC (permalink / raw) To: Brian Gerst; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List Brian Gerst <bgerst@didntduck.org>: > > I realize this may sound like a dumb question...but are sure the card works > > and is not just an inert mass o' silicon? I have couple of 3c509s knocking > > around here myself and I'm not at all sure they're alive. > > Yes, it worked. So there *is* a significant risk of false negatives. Damn. That is not good. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." -- Mohandas Gandhi, An Autobiography, pg 446 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:18 ` Eric S. Raymond 2002-01-03 3:36 ` Brian Gerst @ 2002-01-03 3:39 ` Dave Jones 1 sibling, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-03 3:39 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List On Wed, 2 Jan 2002, Eric S. Raymond wrote: > > Go down the DMI path, and get it right _sometimes_, or take a zero. > > Getting it right sometimes is likely to do more harm than good. > Not in this case. If the DMI read fails, the worst-case result is the > user sees some ISA extra questions. Erm, worse case would surely be "I have ISA cards, and all the options to use them are missing". Sure you could have a button to switch them all back on, but hey! this implies Aunt Tillie knows she has ISA cards which gets everything right back to square one. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:03 ` Eric S. Raymond 2002-01-03 3:26 ` Dave Jones @ 2002-01-03 3:34 ` Brian Gerst 2002-01-03 14:37 ` Horst von Brand 2002-01-04 7:09 ` [OT] " Paul Duncan 2002-01-03 11:25 ` Henrik Hovi 2002-01-03 14:31 ` Horst von Brand 3 siblings, 2 replies; 185+ messages in thread From: Brian Gerst @ 2002-01-03 3:34 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List "Eric S. Raymond" wrote: > > Dave Jones <davej@suse.de>: > > See other posting with examples of dramatic failures of > > 'slots in box, but dmi says none' and 'no slots, dmi says some'. > > still think this is usable ? You're nuts. > > One of my background assumptions is that the older a machine is, the > more likely it is that the person doing the config will have a clue about > what they're doing. These days hardware is so cheap that only geeks try > to cram Linux onto old systems -- and even the geeks mostly do it just to > prove they can. > > Thus I'm not very worried about DMI read failing on older hardware. > My main objective is to make configuration painless on modern PCI-only > hardware -- which is why I want to be able to tell when there are no > ISA slots, so I can deep-six questions about ISA drivers. Then the best thing to do is to put a disclaimer on your autoconfiguration program: "WARNING: autoconfigure may not detect older hardware that was not designed for reliable detection. If autoconfigure fails to detect all of your hardware, you may need to manually configure your kernel." Sometimes perfection isn't worth the effort, especially when trying to support a class of hardware that is rapidly becoming obsolete. Optimize for the most likely case, and deal with the rare corner cases with other means. -- Brian Gerst ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:34 ` Brian Gerst @ 2002-01-03 14:37 ` Horst von Brand 2002-01-04 7:09 ` [OT] " Paul Duncan 1 sibling, 0 replies; 185+ messages in thread From: Horst von Brand @ 2002-01-03 14:37 UTC (permalink / raw) To: Brian Gerst; +Cc: esr, Linux Kernel List Brian Gerst <bgerst@didntduck.org> said: [...] > Then the best thing to do is to put a disclaimer on your > autoconfiguration program: "WARNING: autoconfigure may not detect older > hardware that was not designed for reliable detection. If autoconfigure > fails to detect all of your hardware, you may need to manually configure > your kernel." It is a lot easier just to leave a question in "Do you have old (ISA) cards in your machine?"... solves 95% of the "problem" with minimal effort. The question can then go for "Newbie configuration" in a few years. > Sometimes perfection isn't worth the effort, especially when trying to > support a class of hardware that is rapidly becoming obsolete. Optimize > for the most likely case, and deal with the rare corner cases with other > means. Bingo! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* [OT] Re: ISA slot detection on PCI systems? 2002-01-03 3:34 ` Brian Gerst 2002-01-03 14:37 ` Horst von Brand @ 2002-01-04 7:09 ` Paul Duncan 1 sibling, 0 replies; 185+ messages in thread From: Paul Duncan @ 2002-01-04 7:09 UTC (permalink / raw) To: Brian Gerst; +Cc: linux-kernel * Brian Gerst (bgerst@didntduck.org) wrote: > > Then the best thing to do is to put a disclaimer on your > autoconfiguration program: "WARNING: autoconfigure may not detect older > hardware that was not designed for reliable detection. If autoconfigure > fails to detect all of your hardware, you may need to manually configure > your kernel." That bears a striking resemblance to an auto-detection message I saw almost 7 years ago. ;) > Brian Gerst -- Paul Duncan <pabs@pablotron.org> pabs on #e (OPN IRC) http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:03 ` Eric S. Raymond 2002-01-03 3:26 ` Dave Jones 2002-01-03 3:34 ` Brian Gerst @ 2002-01-03 11:25 ` Henrik Hovi 2002-01-05 7:09 ` H. Peter Anvin 2002-01-03 14:31 ` Horst von Brand 3 siblings, 1 reply; 185+ messages in thread From: Henrik Hovi @ 2002-01-03 11:25 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List The following will be strictly IMHO. Don't take me too seriosly - even I can't most of the time. On Wed, 2 Jan 2002, Eric S. Raymond wrote: > Dave Jones <davej@suse.de>: > > See other posting with examples of dramatic failures of > > 'slots in box, but dmi says none' and 'no slots, dmi says some'. > > still think this is usable ? You're nuts. > > One of my background assumptions is that the older a machine is, the > more likely it is that the person doing the config will have a clue about > what they're doing. These days hardware is so cheap that only geeks try > to cram Linux onto old systems -- and even the geeks mostly do it just to > prove they can. > > Thus I'm not very worried about DMI read failing on older hardware. > My main objective is to make configuration painless on modern PCI-only > hardware -- which is why I want to be able to tell when there are no > ISA slots, so I can deep-six questions about ISA drivers. These days hardware is cheap. BUT most of the people using their computer as a typewriter and a means to easily do the important things with the bank are NOT ready to upgrade to a new state-of-art Itanium 2GHz byte crusher with a nice GeForce 5 accelerator and an integrated coffee cooker (okay, they would like that one) even though they were cheaper than a pair socks. The world doesn't work that way. They don't need such monsters and that's it. I thought Linux was also about coding software that would work with all hardware including computers more than two years old. This DMI thingie seems like it could pretty efficiently fuck up everything with such puters. It would be fine for newer Athlons and P3s if one could trust hardware vendors. > > You're solving a non-problem. > > Some examples of target audience you're aiming for in your previous > > mail were I believe.. > > > > o The geek next door who wants to tinker and learn about the kernel. > > Said geek is going to learn a damn sight more currently than he will > > with a dumbed down pointy clicky "build me a kernel" button. > > Your "they must show willingness to suffer pain, otherwise they're not worthy" > attitude is really showing here. The geek next door is already capable of compiling the kernel by reading a bit of the fine manuals and I wouldn't worry a bit about him not becoming the best kernel hacker in the world. He will get angry with the bugs and the people supposed to fix them sooner or later. The geek next door is what we've all been. Even though there was the easy way, we preferred the hard (and stupid) way. > I'm not proposing that the "dumbed-down" version be the only version, but that > the kernel and the config tools make "build me a kernel at the push of a > button *possible* for those who don't want to go any deeper. > > > o Aunt Tilley. > > Vendors already ship an array of kernels which should make it > > unnecessary for her to have to build a kernel. > > Yes. But *I* want Aunt Tilley to be able to download the latest kernel > sources and build/install them herself, without ever feeling that the task > is beyond her capabilities. Aunt Tilley is the main issue here. An average Aunt Tilley would propably have an oldish machine she can write amateur romantic novels and emails to her nephews with. She'll be perfectly happy with it until it crashes. It is also propable that, if she has Linux on her typewriter, one of her nephews (let's call him Bob) is doing the administration. Although Aunt Tilley is the sweetest person on Earth, Bob doesn't much like about constantly cycling the 20 miles from home to Aunt Tilley's just to compile a kernel. He will propably try his best to teach Aunt Tilley to install the newest kernel-image rpm package form the net from time to time. That should be the direction we're headed. "Forcing" people to use pre-compiled kernels is what we are doing now (and that's what people in Redmond are doing too). I wouldn't expect Aunt Tilley to be genuinely interested in the process of compiling the kernel. She won't know much about it but still, she should be able to do it. If she happened to have one of those computers whose DMI sucks big time and we asked her wether she wanted to get all her ISA devices auto-probed, she would answer yes. When the kernel would panic, Aunt Tilley would be frightened and never upgrade anything again or worse: switch back to Windows which she knows "stable" and "secure". > Part of the reason I want this is for the capability itself; partly I want > it pour encourager les autres -- to demonstrate, by tackling one of the > toughest cases, that much of the complexity and anti-useability of Linux > is an artificial and unnecessary creation of the culture that created it, > rather than a result of actual technical depth of the problem. You cannot tackle this case without first searching an answer which is not DMI. It seems like there was none. It is safer making the autoconfig guess the ISA configuration so that it would work with any computer without non-PNP ISA devices. One or two extra configuration options will hurt no one. > I believe we need to learn the discipline of useability and take it seriously. > Because talk plus code is much more convincing than just talk, I'm trying > to demonstrate this by coding. But I'll talk about it too :-). > > > If you still think world domination is going to appear by idiotproofing > > the kernel build process, I think you're in for a surprise. > > We have far bigger usability problems in userspace. The point is that > > $newcomertolinux doesn't need to know what a kernel is, let alone > > have to build one. They just see "Booting progress" "Log in" "Desktop". A newcomer doesn't know what a kernel is but the security of his/her data is the reason why we need to tell him/her. Pre-compiled kernels might come with bugs already fixed (which makes them also wide known). > Sure we have bigger idiotproofing problems. But this is the one that > (a) my skillset is well matched to, and (b) no one else is worrying about. There is another way to idiotproof software. We need good manuals, not just the laughable man pages and the Documentation directory in the source package. WTFM so that $ordinaryperson can RTFM. We should also learn another thing from the commercial world: product placement. Even though there are manuals I would classify as average, they are not where they're supposed to be and people have to do some serious googling before they can solve a minor problem not covered properly by the man page or linuxdoc.org. > World domination will happen, if it happens, because lots of people > are willing to obsess about useability issues at *all* levels of the > system. Including this one. Eric, you're a big dreamer and you have wonderful dreams, but please keep yourself near to the ground. This is not too big a problem. My P133 has two ISA devices and they both are ISAPNP. That computer just had it's seventh birthday. If the automatised configuration makes guesses good enough, the dear old byte crusher will be just fine. And Dave, what's wrong with world domination anyway? ;) Henrik ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 11:25 ` Henrik Hovi @ 2002-01-05 7:09 ` H. Peter Anvin 0 siblings, 0 replies; 185+ messages in thread From: H. Peter Anvin @ 2002-01-05 7:09 UTC (permalink / raw) To: linux-kernel Followup to: <Pine.LNX.4.40.0201031150090.2600-100000@marvin.loppu.net> By author: Henrik Hovi <henrik.hovi@loppu.net> In newsgroup: linux.dev.kernel > > These days hardware is cheap. BUT most of the people using their computer > as a typewriter and a means to easily do the important things with the > bank are NOT ready to upgrade to a new state-of-art Itanium 2GHz byte > crusher with a nice GeForce 5 accelerator and an integrated coffee cooker > (okay, they would like that one) even though they were cheaper than a > pair socks. The world doesn't work that way. They don't need such > monsters and that's it. > They also, usually, don't need to build customized kernels. In fact, I would argue that for *those* people, anything that gets in the way of dynamic autodetection (plop a new card in your machine, or connect a new thing to your USB/PCMCIA/FireWire/ADB/SCSI bus, and the machine should work on the next boot *without* having to go though a recompilation process) is a major mistake. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 3:03 ` Eric S. Raymond ` (2 preceding siblings ...) 2002-01-03 11:25 ` Henrik Hovi @ 2002-01-03 14:31 ` Horst von Brand 2002-01-03 15:00 ` Jesse Pollard 2002-01-03 15:15 ` Richard B. Johnson 3 siblings, 2 replies; 185+ messages in thread From: Horst von Brand @ 2002-01-03 14:31 UTC (permalink / raw) To: Eric S. Raymond, Linux Kernel List "Eric S. Raymond" <esr@thyrsus.com> said: [...] > Yes. But *I* want Aunt Tilley to be able to download the latest kernel > sources and build/install them herself, without ever feeling that the task > is beyond her capabilities. Come on, how many Aunts do you have that even know (or care) what a "kernel" is, let alone think of "building the latest from source"? > Part of the reason I want this is for the capability itself; partly I want > it pour encourager les autres -- to demonstrate, by tackling one of the > toughest cases, that much of the complexity and anti-useability of Linux > is an artificial and unnecessary creation of the culture that created it, > rather than a result of actual technical depth of the problem. Then do your demonstration on something that is actually useful in real life, non? Like making using Linux + Apache + <whatever> easier to use for secure websites (I've recently read that MS IIS is doing _large_ inroads there). That could make a real difference in "World domination. Fast." -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 14:31 ` Horst von Brand @ 2002-01-03 15:00 ` Jesse Pollard 2002-01-03 15:15 ` Richard B. Johnson 1 sibling, 0 replies; 185+ messages in thread From: Jesse Pollard @ 2002-01-03 15:00 UTC (permalink / raw) To: vonbrand, Eric S. Raymond, Linux Kernel List --------- Received message begins Here --------- > > "Eric S. Raymond" <esr@thyrsus.com> said: > > [...] > > > Yes. But *I* want Aunt Tilley to be able to download the latest kernel > > sources and build/install them herself, without ever feeling that the task > > is beyond her capabilities. > > Come on, how many Aunts do you have that even know (or care) what a > "kernel" is, let alone think of "building the latest from source"? > > > Part of the reason I want this is for the capability itself; partly I want > > it pour encourager les autres -- to demonstrate, by tackling one of the > > toughest cases, that much of the complexity and anti-useability of Linux > > is an artificial and unnecessary creation of the culture that created it, > > rather than a result of actual technical depth of the problem. > > Then do your demonstration on something that is actually useful in real > life, non? Like making using Linux + Apache + <whatever> easier to use for > secure websites (I've recently read that MS IIS is doing _large_ inroads > there). That could make a real difference in "World domination. Fast." IIS and the phrase "secure websites" in one sentance ??? IIS can't be made secure, even if it is used at sites that claim to be "secure". This is a different problem domain from kernel configuration. You are referring to an expert system for system administration. Or perhaps a "System Administrators Assistant" program. (How about "Security Administrators Assitant" ...) Not an unreasonable project - just not one that can realistically be completed. Maybe a "good enough" one though ... ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil Any opinions expressed are solely my own. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 14:31 ` Horst von Brand 2002-01-03 15:00 ` Jesse Pollard @ 2002-01-03 15:15 ` Richard B. Johnson 2002-01-04 15:30 ` Kai Henningsen 1 sibling, 1 reply; 185+ messages in thread From: Richard B. Johnson @ 2002-01-03 15:15 UTC (permalink / raw) To: Horst von Brand; +Cc: Eric S. Raymond, Linux Kernel List On Thu, 3 Jan 2002, Horst von Brand wrote: > "Eric S. Raymond" <esr@thyrsus.com> said: > > [...] > > > Yes. But *I* want Aunt Tilley to be able to download the latest kernel > > sources and build/install them herself, without ever feeling that the task > > is beyond her capabilities. > > Come on, how many Aunts do you have that even know (or care) what a > "kernel" is, let alone think of "building the latest from source"? > > > Part of the reason I want this is for the capability itself; partly I want > > it pour encourager les autres -- to demonstrate, by tackling one of the > > toughest cases, that much of the complexity and anti-useability of Linux > > is an artificial and unnecessary creation of the culture that created it, > > rather than a result of actual technical depth of the problem. > > Then do your demonstration on something that is actually useful in real > life, non? Like making using Linux + Apache + <whatever> easier to use for > secure websites (I've recently read that MS IIS is doing _large_ inroads > there). That could make a real difference in "World domination. Fast." > -- > Dr. Horst H. von Brand User #22616 counter.li.org > Departamento de Informatica Fono: +56 32 654431 > Universidad Tecnica Federico Santa Maria +56 32 654239 > Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 "is an artificial and unnecessary creation of the culture that created it.." WRONG! It's not the culture, it's the hardware. PCI has a vendor and device ID code in addition to dynamic addressing and dynamic resource allocation. It is, therefore, theoretically possible to perfectly configure any system with no user input required. ISA has nothing. Just fixed port addressing where an attempt is made to find out something about the hardware by writing and reading the results. If you think you have device 'A' at port N, but you don't, and you write something to condition device 'A' for a response, you could, in fact, tell another device to hit the reset switch or, worse, format your disk(s). These problems are exacerbated because ISA devices typically don't decode all the address bits. You could have a hard-disk controller aliased to the same address as your new communications widget. Basically ISA == JUNK and "modern" users continue to use this obsolete interface bus. Because there are certain ISA port addresses that have historically been used for certain devices, it is possible to probe and configure a high percentage of devices based upon software with a historical knowledge. However, when a new device comes along, all bets are off. For this reason, "plug-and-play" for ISA devices isn't reliable and can't ever be. Apple also has limited address space for devices. However, since the apple-sauce machine peripherals were all made under license, because the architecture was closed, this assured that there were not any duplicate decodes. It also made probing unnecessary. Modern apple-sauce machines have PCI so, just like modern Intel/PC machines, no probing is necessary. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips). I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 15:15 ` Richard B. Johnson @ 2002-01-04 15:30 ` Kai Henningsen 0 siblings, 0 replies; 185+ messages in thread From: Kai Henningsen @ 2002-01-04 15:30 UTC (permalink / raw) To: linux-kernel root@chaos.analogic.com (Richard B. Johnson) wrote on 03.01.02 in <Pine.LNX.3.95.1020103100747.4554A-100000@chaos.analogic.com>: > ISA has nothing. Just fixed port addressing where an attempt > is made to find out something about the hardware by writing > and reading the results. If you think you have device 'A' > at port N, but you don't, and you write something to condition > device 'A' for a response, you could, in fact, tell another > device to hit the reset switch or, worse, format your disk(s). Best-known example is probably trying to autodetect anything but a NE2000 card before detecting the NE2000 card that's in the machine. I've even seen BIOSes freeze in that situation. And yes, I do mean whole- machine-freeze. An NE2000 *really* doesn't like being touched the wrong way. MfG Kai ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 2:44 ` Dave Jones 2002-01-03 3:03 ` Eric S. Raymond @ 2002-01-03 5:30 ` Andrew Morton 2002-01-03 5:42 ` Jeff Garzik 2002-01-03 5:46 ` Eric S. Raymond 2002-01-03 9:14 ` David Woodhouse 2 siblings, 2 replies; 185+ messages in thread From: Andrew Morton @ 2002-01-03 5:30 UTC (permalink / raw) To: Dave Jones; +Cc: Eric S. Raymond, Lionel Bouton, Alan Cox, Linux Kernel List Dave Jones wrote: > > o Aunt Tilley. > Vendors already ship an array of kernels which should make it > unnecessary for her to have to build a kernel. > There is a clear advantage to kernel developers in making things as easy as possible for Aunt Tilley to use our latest output. If the difficulty of installing the latest kernel prevents her from doing that, she loses. And so do we, because we don't get to know if we've fixed her problem. If Eric can get the entire download-config-build-install process down to a single mouse click, he'll have done us all a great service. - ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 5:30 ` Andrew Morton @ 2002-01-03 5:42 ` Jeff Garzik 2002-01-03 5:55 ` Daniel Phillips 2002-01-03 5:46 ` Eric S. Raymond 1 sibling, 1 reply; 185+ messages in thread From: Jeff Garzik @ 2002-01-03 5:42 UTC (permalink / raw) To: Andrew Morton Cc: Dave Jones, Eric S. Raymond, Lionel Bouton, Alan Cox, Linux Kernel List Andrew Morton wrote: > > Dave Jones wrote: > > > > o Aunt Tilley. > > Vendors already ship an array of kernels which should make it > > unnecessary for her to have to build a kernel. > > > > There is a clear advantage to kernel developers in making things as > easy as possible for Aunt Tilley to use our latest output. > > If the difficulty of installing the latest kernel prevents her from > doing that, she loses. And so do we, because we don't get to know > if we've fixed her problem. > > If Eric can get the entire download-config-build-install process > down to a single mouse click, he'll have done us all a great service. OTOH if dumbing down the kernel config costs kernel developers productivity and increases the noise-to-signal ratio on lkml, it's a disservice... Jeff -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 5:42 ` Jeff Garzik @ 2002-01-03 5:55 ` Daniel Phillips 0 siblings, 0 replies; 185+ messages in thread From: Daniel Phillips @ 2002-01-03 5:55 UTC (permalink / raw) To: Jeff Garzik, Andrew Morton Cc: Dave Jones, Eric S. Raymond, Lionel Bouton, Alan Cox, Linux Kernel List On January 3, 2002 06:42 am, Jeff Garzik wrote: > Andrew Morton wrote: > > > > Dave Jones wrote: > > > > > > o Aunt Tilley. > > > Vendors already ship an array of kernels which should make it > > > unnecessary for her to have to build a kernel. > > > > > > > There is a clear advantage to kernel developers in making things as > > easy as possible for Aunt Tilley to use our latest output. > > > > If the difficulty of installing the latest kernel prevents her from > > doing that, she loses. And so do we, because we don't get to know > > if we've fixed her problem. > > > > If Eric can get the entire download-config-build-install process > > down to a single mouse click, he'll have done us all a great service. > > OTOH if dumbing down the kernel config costs kernel developers > productivity and increases the noise-to-signal ratio on lkml, it's a > disservice... Have you tried Eric's config code lately? It's getting *really nice*. The 'search' feature alone makes it worth it, and the intelligent tree organization, and the consistency rules, and... I'm now configging 2.4.17 with Eric-config, other trees with good-old-config, and I can tell you which one I prefer. -- Daniel ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 5:30 ` Andrew Morton 2002-01-03 5:42 ` Jeff Garzik @ 2002-01-03 5:46 ` Eric S. Raymond 1 sibling, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 5:46 UTC (permalink / raw) To: Andrew Morton Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List, kbuild-devel Andrew Morton <akpm@zip.com.au>: > If Eric can get the entire download-config-build-install process > down to a single mouse click, he'll have done us all a great service. Single-mouse-click configuration isn't going to happen soon. It may not happen at all. However, I believe pushing in that direction is worthwhile. Configuration *can* be made a helluva lot easier than it is now. Easier than I think most kernel developers would believe possible, at least before sitting down to a serious think and abandoning a lot of long-held assumptions about how things `have' to be. CML2 was the first step. It gives us a tool that can guarantee the correctness and consistency of configuration changes according to a rulebase. The autoconfigurator that Giacomo Catenazzi started, which I am now integrating with CML2, is the next step. I expect it to reduce the task complexity for typical configuration cases by 90%. It's pretty effective, including more than 2500 probes. I don't know what the third step will be yet. It depends partly on what that remaining 10% looks like. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficient...The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well meaning but without understanding." -- Supreme Court Justice Louis Brandeis ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 2:44 ` Dave Jones 2002-01-03 3:03 ` Eric S. Raymond 2002-01-03 5:30 ` Andrew Morton @ 2002-01-03 9:14 ` David Woodhouse 2002-01-03 9:09 ` Eric S. Raymond 2002-01-03 9:24 ` David Woodhouse 2 siblings, 2 replies; 185+ messages in thread From: David Woodhouse @ 2002-01-03 9:14 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List Eric, what are you doing to do if you _do_ detect that there are ISA slots present? If there are ISA (not isapnp) cards present, you'll _have_ to start asking 'difficult' questions. So why bother to detect the ISA slots automatically? Just hide the ISA_SLOTS option in idiotmode. I hope you haven't added ISA_SLOTS to the version of CML2 you're intending to submit for 2.5, btw. That would violate the agreement which you seem to have made that you'd make the first version of CML2 match the existing CML1 rules as far as possible, and introduce orthogonal changes later in individual patches. -- dwmw2 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:14 ` David Woodhouse @ 2002-01-03 9:09 ` Eric S. Raymond 2002-01-03 12:14 ` Alan Cox 2002-01-03 16:52 ` Rik van Riel 2002-01-03 9:24 ` David Woodhouse 1 sibling, 2 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 9:09 UTC (permalink / raw) To: David Woodhouse; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List David Woodhouse <dwmw2@infradead.org>: > Eric, what are you doing to do if you _do_ detect that there are ISA slots > present? If there are ISA (not isapnp) cards present, you'll _have_ to > start asking 'difficult' questions. So why bother to detect the ISA slots > automatically? Just hide the ISA_SLOTS option in idiotmode. You have my intentions backwards. What I'd like to be able to do is suppress ISA_SLOTS when there are detectably *no* ISA cards. Unfortunately I have had it demonstrated that the DMI tables can give false negatives (false positives would not have been a showstopper). -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:09 ` Eric S. Raymond @ 2002-01-03 12:14 ` Alan Cox 2002-01-03 12:34 ` Vojtech Pavlik 2002-01-03 16:52 ` Rik van Riel 1 sibling, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-03 12:14 UTC (permalink / raw) To: esr; +Cc: David Woodhouse, Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List > You have my intentions backwards. What I'd like to be able to do is > suppress ISA_SLOTS when there are detectably *no* ISA cards. Unfortunately > I have had it demonstrated that the DMI tables can give false negatives > (false positives would not have been a showstopper). Thats why I also suggested using lspci and looking for an ISA bridge. If you have no PCI its probably ISA. If you have no PCI/ISA bridge its very very unlikely to be ISA ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:14 ` Alan Cox @ 2002-01-03 12:34 ` Vojtech Pavlik 2002-01-04 18:28 ` Maciej W. Rozycki 0 siblings, 1 reply; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-03 12:34 UTC (permalink / raw) To: Alan Cox; +Cc: esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Thu, Jan 03, 2002 at 12:14:47PM +0000, Alan Cox wrote: > > You have my intentions backwards. What I'd like to be able to do is > > suppress ISA_SLOTS when there are detectably *no* ISA cards. Unfortunately > > I have had it demonstrated that the DMI tables can give false negatives > > (false positives would not have been a showstopper). > > Thats why I also suggested using lspci and looking for an ISA bridge. > If you have no PCI its probably ISA. If you have no PCI/ISA bridge its > very very unlikely to be ISA Uh, no. Almost all 486 PCI boards and early Pentium/K5/K6 boards have the PCI bus hanging of the VLB or other local bus, and on those ISA isn't behind an ISA bridge. These chipsets do have ISA but no ISA bridge. To name one example: VIA Apollo Master, vt82c570 chipset has only Host Bridge and IDE Controller visible on the PCI bus. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:34 ` Vojtech Pavlik @ 2002-01-04 18:28 ` Maciej W. Rozycki 2002-01-04 19:04 ` Vojtech Pavlik 0 siblings, 1 reply; 185+ messages in thread From: Maciej W. Rozycki @ 2002-01-04 18:28 UTC (permalink / raw) To: Vojtech Pavlik Cc: Alan Cox, esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Thu, 3 Jan 2002, Vojtech Pavlik wrote: > > Thats why I also suggested using lspci and looking for an ISA bridge. > > If you have no PCI its probably ISA. If you have no PCI/ISA bridge its > > very very unlikely to be ISA > > Uh, no. Almost all 486 PCI boards and early Pentium/K5/K6 boards have > the PCI bus hanging of the VLB or other local bus, and on those ISA > isn't behind an ISA bridge. These chipsets do have ISA but no ISA > bridge. These can be checked for explicitly as the list isn't likely to grow. I can dig a few Intel docs for IDs of 486-class PCI chipsets that have no PCI-ISA bridge if they'd be useful. Also note that there are PCI-ISA bridges that are reported as "non-VGA unclassified" devices as they predate PCI 2.0. The SIO (82378IB/ZB) comes to mind here. The bridge is used in certain models of Alpha systems as well. The bridges would need to be listed by IDs, too. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 18:28 ` Maciej W. Rozycki @ 2002-01-04 19:04 ` Vojtech Pavlik 2002-01-04 19:05 ` Eric S. Raymond 2002-01-04 19:36 ` Maciej W. Rozycki 0 siblings, 2 replies; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-04 19:04 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Alan Cox, esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, Jan 04, 2002 at 07:28:58PM +0100, Maciej W. Rozycki wrote: > > > Thats why I also suggested using lspci and looking for an ISA bridge. > > > If you have no PCI its probably ISA. If you have no PCI/ISA bridge its > > > very very unlikely to be ISA > > > > Uh, no. Almost all 486 PCI boards and early Pentium/K5/K6 boards have > > the PCI bus hanging of the VLB or other local bus, and on those ISA > > isn't behind an ISA bridge. These chipsets do have ISA but no ISA > > bridge. > > These can be checked for explicitly as the list isn't likely to grow. I > can dig a few Intel docs for IDs of 486-class PCI chipsets that have no > PCI-ISA bridge if they'd be useful. > > Also note that there are PCI-ISA bridges that are reported as "non-VGA > unclassified" devices as they predate PCI 2.0. The SIO (82378IB/ZB) comes > to mind here. The bridge is used in certain models of Alpha systems as > well. The bridges would need to be listed by IDs, too. And of course, there will be a huge amount of false positives, because all the new chipsets have an ISA bridge built into the southbridge chip and it is there even when no ISA slots are present. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:04 ` Vojtech Pavlik @ 2002-01-04 19:05 ` Eric S. Raymond 2002-01-04 19:21 ` Vojtech Pavlik ` (2 more replies) 2002-01-04 19:36 ` Maciej W. Rozycki 1 sibling, 3 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-04 19:05 UTC (permalink / raw) To: Vojtech Pavlik Cc: Maciej W. Rozycki, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List Vojtech Pavlik <vojtech@suse.cz>: > And of course, there will be a huge amount of false positives, because > all the new chipsets have an ISA bridge built into the southbridge chip > and it is there even when no ISA slots are present. Yeah. That's what makes the lspci approach unusable for my purposes. The approach I want to take is this: 1. Get guaranteed access to the DMI data, either via a /{proc,sys}/dmi or /var/run/dmi initialized at boot time. 2. Develop an exception list of mobos that have ISA slots that don't show up under DMI. My logic would then be: if the box has PCI, and DMI shows no ISA slots, and the motherboard is not on the exception list, then suppress ISA questions. This would be a kluge, but it would have the advantage that the exception list is finite and can be expected to stop growing. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The end move in politics is always to pick up a gun. -- R. Buckminster Fuller ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:05 ` Eric S. Raymond @ 2002-01-04 19:21 ` Vojtech Pavlik 2002-01-04 19:41 ` Eric S. Raymond 2002-01-04 19:45 ` Dave Jones 2002-01-04 19:50 ` Maciej W. Rozycki 2 siblings, 1 reply; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-04 19:21 UTC (permalink / raw) To: Eric S. Raymond, Maciej W. Rozycki, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, Jan 04, 2002 at 02:05:38PM -0500, Eric S. Raymond wrote: > Vojtech Pavlik <vojtech@suse.cz>: > > And of course, there will be a huge amount of false positives, because > > all the new chipsets have an ISA bridge built into the southbridge chip > > and it is there even when no ISA slots are present. > > Yeah. That's what makes the lspci approach unusable for my purposes. > > The approach I want to take is this: > > 1. Get guaranteed access to the DMI data, either via a /{proc,sys}/dmi > or /var/run/dmi initialized at boot time. > > 2. Develop an exception list of mobos that have ISA slots that don't > show up under DMI. > > My logic would then be: if the box has PCI, and DMI shows no ISA slots, > and the motherboard is not on the exception list, then suppress ISA > questions. > > This would be a kluge, but it would have the advantage that the exception > list is finite and can be expected to stop growing. You'll have to add motherboards that have no ISA slots, but onboard ISA devices to the list. I'd suggest looking at the output of /proc/bus/isapnp as well, because if it lists any devices, you certainly need ISA support. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:21 ` Vojtech Pavlik @ 2002-01-04 19:41 ` Eric S. Raymond 2002-01-04 20:09 ` Dave Jones ` (2 more replies) 0 siblings, 3 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-04 19:41 UTC (permalink / raw) To: Vojtech Pavlik Cc: Maciej W. Rozycki, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List Vojtech Pavlik <vojtech@suse.cz>: > You'll have to add motherboards that have no ISA slots, but onboard ISA > devices to the list. > > I'd suggest looking at the output of /proc/bus/isapnp as well, because > if it lists any devices, you certainly need ISA support. OK, apparently some people are still confused about what I'm trying to do. That's no surprise. It confuses *me* sometimes! The issue is not ISA support, it is ISA *card* support. At the moment, and for the foreseeable future, X86 implies ISA. Someday there may be X86 motherboards without on-board ISA devices, but that's a few years off. When that does happen, my logic will be something like this, where PCI_BRIDGE is the test for whether PC reports an ISA bridge. X86 and ((PCI and ISA_BRIDGE) or not PCI) => ISA The "not PCI" case represents old ISA-only machines. What I'm actually trying to do is determine whether the machine can take ISA *cards*, and use that computation to suppress questions about ISA cards (probed ones would still be found). For this, the logic should look as follows, where: * DMI means "reports DMI" * DMI_ISA means "DMI reports ISA slots" * BLACKLISTED means the motherboard is in an exception list of PCI-supporting, DMI-supporting motherboards that falsely claim not to have ISA slots. X86 and ((not PCI) or (not DMI) or DMI_ISA or BLACKLISTED => ISA_CARDS This is one reason I want /sys/dmi -- because if I *don't* see it, that means I should assume the machine is old enough to take ISA cards. This filter should make the blacklist relatively small -- we wouldn't have to track even PCI motherboards older than the DMI standard. A key point is that as ISA phases out (near future now), the blacklist will stop growing. Ballpark guess is it will top out below 150 entries. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> If I were to select a jack-booted group of fascists who are perhaps as large a danger to American society as I could pick today, I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. -- U.S. Representative John Dingell, 1980 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:41 ` Eric S. Raymond @ 2002-01-04 20:09 ` Dave Jones 2002-01-08 12:52 ` Rob Landley 2002-01-04 20:19 ` David Weinehall 2002-01-04 20:20 ` Vojtech Pavlik 2 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-04 20:09 UTC (permalink / raw) To: Eric S. Raymond Cc: Vojtech Pavlik, Maciej W. Rozycki, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Eric S. Raymond wrote: > X86 and ((not PCI) or (not DMI) or DMI_ISA or BLACKLISTED => ISA_CARDS You'd also need (not MCA) (not VLBUS) (not Other arcane non-ISA buses) > A key point is that as ISA phases out (near future now), the blacklist > will stop growing. Ballpark guess is it will top out below 150 entries. I showed you 4 examples of bad DMI tables found within 5 minutes of testing here. I'm one person. There's a lot of hardware out there, with a lot of broken BIOSes. (Yes, you have different bugs per BIOS, with sometimes a dozen or so revisions just for 1 board). -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:09 ` Dave Jones @ 2002-01-08 12:52 ` Rob Landley 0 siblings, 0 replies; 185+ messages in thread From: Rob Landley @ 2002-01-08 12:52 UTC (permalink / raw) To: Dave Jones, linux-kernel, esr On Friday 04 January 2002 03:09 pm, Dave Jones wrote: > On Fri, 4 Jan 2002, Eric S. Raymond wrote: > > X86 and ((not PCI) or (not DMI) or DMI_ISA or BLACKLISTED => ISA_CARDS > > You'd also need (not MCA) (not VLBUS) (not Other arcane non-ISA buses) VLBUS is ISA. It's a bag on the side of ISA. You can stick an 8 or 16 bit ISA card into a VLBUS slot. Rob ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:41 ` Eric S. Raymond 2002-01-04 20:09 ` Dave Jones @ 2002-01-04 20:19 ` David Weinehall 2002-01-04 20:30 ` Maciej W. Rozycki 2002-01-04 20:20 ` Vojtech Pavlik 2 siblings, 1 reply; 185+ messages in thread From: David Weinehall @ 2002-01-04 20:19 UTC (permalink / raw) To: Eric S. Raymond, Vojtech Pavlik, Maciej W. Rozycki, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, Jan 04, 2002 at 02:41:46PM -0500, Eric S. Raymond wrote: [snip] > This is one reason I want /sys/dmi -- because if I *don't* see it, that > means I should assume the machine is old enough to take ISA cards. This > filter should make the blacklist relatively small -- we wouldn't have to > track even PCI motherboards older than the DMI standard. If you find an MCA-bus, you can suppress most (but not all) ISA-cards too (some of the cards support MCA without having any extra MCA-related code in the drivers, such as the eexpress-driver, but I can help with such a list if necessary.) /David _ _ // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:19 ` David Weinehall @ 2002-01-04 20:30 ` Maciej W. Rozycki 2002-01-04 20:36 ` Eric S. Raymond 0 siblings, 1 reply; 185+ messages in thread From: Maciej W. Rozycki @ 2002-01-04 20:30 UTC (permalink / raw) To: David Weinehall Cc: Eric S. Raymond, Vojtech Pavlik, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, David Weinehall wrote: > If you find an MCA-bus, you can suppress most (but not all) ISA-cards > too (some of the cards support MCA without having any extra MCA-related > code in the drivers, such as the eexpress-driver, but I can help with > such a list if necessary.) Shouldn't the drivers depend on "CONFIG_ISA or CONFIG_MCA" then? Just like CONFIG_DEFXX depends on "CONFIG_PCI or CONFIG_EISA"? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:30 ` Maciej W. Rozycki @ 2002-01-04 20:36 ` Eric S. Raymond 2002-01-05 7:12 ` H. Peter Anvin 0 siblings, 1 reply; 185+ messages in thread From: Eric S. Raymond @ 2002-01-04 20:36 UTC (permalink / raw) To: Maciej W. Rozycki Cc: David Weinehall, Vojtech Pavlik, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List Maciej W. Rozycki <macro@ds2.pg.gda.pl>: > > If you find an MCA-bus, you can suppress most (but not all) ISA-cards > > too (some of the cards support MCA without having any extra MCA-related > > code in the drivers, such as the eexpress-driver, but I can help with > > such a list if necessary.) > > Shouldn't the drivers depend on "CONFIG_ISA or CONFIG_MCA" then? Just > like CONFIG_DEFXX depends on "CONFIG_PCI or CONFIG_EISA"? Yes, that's almost the right solution (CONFIG_ISACARDS or CONFIG_MCA). I'll add require MCA != ISA_CARDS to the rulebase. Not that there are a lot of MCA machines out there but every little bit helps. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, "Beyond This Horizon", 1942 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:36 ` Eric S. Raymond @ 2002-01-05 7:12 ` H. Peter Anvin 0 siblings, 0 replies; 185+ messages in thread From: H. Peter Anvin @ 2002-01-05 7:12 UTC (permalink / raw) To: linux-kernel Followup to: <20020104153646.D20097@thyrsus.com> By author: "Eric S. Raymond" <esr@thyrsus.com> In newsgroup: linux.dev.kernel > > Yes, that's almost the right solution (CONFIG_ISACARDS or CONFIG_MCA). > I'll add > > require MCA != ISA_CARDS > > to the rulebase. Not that there are a lot of MCA machines out there but > every little bit helps. > Does that mean you can't build a kernel which will work on both kinds of machines? If so, start over, broken idea. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:41 ` Eric S. Raymond 2002-01-04 20:09 ` Dave Jones 2002-01-04 20:19 ` David Weinehall @ 2002-01-04 20:20 ` Vojtech Pavlik 2002-01-04 20:44 ` Eric S. Raymond 2 siblings, 1 reply; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-04 20:20 UTC (permalink / raw) To: Eric S. Raymond, Maciej W. Rozycki, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, Jan 04, 2002 at 02:41:46PM -0500, Eric S. Raymond wrote: > Vojtech Pavlik <vojtech@suse.cz>: > > You'll have to add motherboards that have no ISA slots, but onboard ISA > > devices to the list. > > > > I'd suggest looking at the output of /proc/bus/isapnp as well, because > > if it lists any devices, you certainly need ISA support. > > OK, apparently some people are still confused about what I'm trying to do. > That's no surprise. It confuses *me* sometimes! I think I understand you. The problem is that many ISA chips (sound, others) that are normally used on ISA cards, and thus handled by drivers most likely labeled by the ISA_CARDS flag, can be, and were often integrated onto mainboards, even if those didn't have any ISA slots. Think (possibly older generation, like P-MMX based) notebooks ... there you can have X86 ... true PCI ... true DMI ... true DMI_ISA ... false BLACKLISTED ... possibly true, if you blacklist most notebooks and yet have many ISA drivers needed for proper operation of the machine. > > The issue is not ISA support, it is ISA *card* support. At the moment, > and for the foreseeable future, X86 implies ISA. Someday there may be > X86 motherboards without on-board ISA devices, but that's a few years off. > When that does happen, my logic will be something like this, where > PCI_BRIDGE is the test for whether PC reports an ISA bridge. > > X86 and ((PCI and ISA_BRIDGE) or not PCI) => ISA > > The "not PCI" case represents old ISA-only machines. > > What I'm actually trying to do is determine whether the machine can > take ISA *cards*, and use that computation to suppress questions about > ISA cards (probed ones would still be found). For this, the logic > should look as follows, where: > > * DMI means "reports DMI" > * DMI_ISA means "DMI reports ISA slots" > * BLACKLISTED means the motherboard is in an exception list of PCI-supporting, > DMI-supporting motherboards that falsely claim not to have ISA slots. > > X86 and ((not PCI) or (not DMI) or DMI_ISA or BLACKLISTED => ISA_CARDS > > This is one reason I want /sys/dmi -- because if I *don't* see it, that > means I should assume the machine is old enough to take ISA cards. This > filter should make the blacklist relatively small -- we wouldn't have to > track even PCI motherboards older than the DMI standard. > > A key point is that as ISA phases out (near future now), the blacklist > will stop growing. Ballpark guess is it will top out below 150 entries. > -- > <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> > > If I were to select a jack-booted group of fascists who are > perhaps as large a danger to American society as I could pick today, > I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. > -- U.S. Representative John Dingell, 1980 -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:20 ` Vojtech Pavlik @ 2002-01-04 20:44 ` Eric S. Raymond 0 siblings, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-04 20:44 UTC (permalink / raw) To: Vojtech Pavlik Cc: Maciej W. Rozycki, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List Vojtech Pavlik <vojtech@suse.cz>: > I think I understand you. The problem is that many ISA chips (sound, > others) that are normally used on ISA cards, and thus handled by drivers > most likely labeled by the ISA_CARDS flag, can be, and were often > integrated onto mainboards, even if those didn't have any ISA slots. > > Think (possibly older generation, like P-MMX based) notebooks ... there > you can have > > X86 ... true > PCI ... true > DMI ... true > DMI_ISA ... false > BLACKLISTED ... possibly true, if you blacklist most notebooks > > and yet have many ISA drivers needed for proper operation of the > machine. That would sure pump up the blacklist, all right. I think at this point the right thing for me to do is gather data on the scope of the problem. I have some ideas about that. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> It is the assumption of this book that a work of art is a gift, not a commodity. Or, to state the modern case with more precision, that works of art exist simultaneously in two "economies," a market economy and a gift economy. Only one of these is essential, however: a work of art can survive without the market, but where there is no gift there is no art. -- Lewis Hyde, The Gift: Imagination and the Erotic Life of Property ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:05 ` Eric S. Raymond 2002-01-04 19:21 ` Vojtech Pavlik @ 2002-01-04 19:45 ` Dave Jones 2002-01-04 19:50 ` Maciej W. Rozycki 2 siblings, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-04 19:45 UTC (permalink / raw) To: Eric S. Raymond Cc: Vojtech Pavlik, Maciej W. Rozycki, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Eric S. Raymond wrote: > 2. Develop an exception list of mobos that have ISA slots that don't > show up under DMI. You forgot "And show the ISA questions for non-DMI aware PCI systems (that *might* have ISA)" > This would be a kluge, but it would have the advantage that the > exception list is finite and can be expected to stop growing. I find your faith in BIOS developers amusing. 8) -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:05 ` Eric S. Raymond 2002-01-04 19:21 ` Vojtech Pavlik 2002-01-04 19:45 ` Dave Jones @ 2002-01-04 19:50 ` Maciej W. Rozycki 2002-01-04 19:54 ` Dave Jones 2 siblings, 1 reply; 185+ messages in thread From: Maciej W. Rozycki @ 2002-01-04 19:50 UTC (permalink / raw) To: Eric S. Raymond Cc: Vojtech Pavlik, Alan Cox, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Eric S. Raymond wrote: > My logic would then be: if the box has PCI, and DMI shows no ISA slots, > and the motherboard is not on the exception list, then suppress ISA > questions. What about CONFIG_BLK_DEV_FD, CONFIG_SERIAL and CONFIG_PARPORT_PC? ISA devices of this kind are still often present in systems even if no ISA slots exist. Actually CONFIG_BLK_DEV_FD is purely ISA and it uses ISA DMA (so it requires kernel/dma.c, which is ISA-only). An example of such a system stands next to me now -- no ISA slots but all of the above devices. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:50 ` Maciej W. Rozycki @ 2002-01-04 19:54 ` Dave Jones 2002-01-04 20:24 ` Maciej W. Rozycki 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-04 19:54 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Eric S. Raymond, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Maciej W. Rozycki wrote: > What about CONFIG_BLK_DEV_FD, CONFIG_SERIAL and CONFIG_PARPORT_PC? ISA > devices of this kind are still often present in systems even if no ISA > slots exist. Actually CONFIG_BLK_DEV_FD is purely ISA and it uses ISA DMA > (so it requires kernel/dma.c, which is ISA-only). At the beginning of this thread I believe it was discussed splitting the config option into CONFIG_ISA and CONFIG_ISASLOTS -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:54 ` Dave Jones @ 2002-01-04 20:24 ` Maciej W. Rozycki 2002-01-04 20:31 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Maciej W. Rozycki @ 2002-01-04 20:24 UTC (permalink / raw) To: Dave Jones Cc: Eric S. Raymond, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Dave Jones wrote: > At the beginning of this thread I believe it was discussed splitting > the config option into CONFIG_ISA and CONFIG_ISASLOTS That seems impossible in the real world. I don't think it's possible to detect physical connectors on a PCB for any bus -- I've even seen boards with soldering spots for bus connectors but no connectors themselves. Relying on reporting anything optional being done right by a BIOS is an illusion -- even mandatory things are screwed in many PC BIOSes. For the said boards firmware is likely identical as for ones with real connectors. Also the choice of devices to depend on CONFIG_ISASLOTS is tough? How do you know which ones exist in an on-board configuration somewhere and which ones do not? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:24 ` Maciej W. Rozycki @ 2002-01-04 20:31 ` Dave Jones 2002-01-04 20:33 ` Eric S. Raymond 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-04 20:31 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Eric S. Raymond, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Maciej W. Rozycki wrote: > That seems impossible in the real world. I don't think it's possible to > detect physical connectors on a PCB for any bus -- I've even seen boards > with soldering spots for bus connectors but no connectors themselves. I agree. The best you can do is make educated guesses... > Relying on reporting anything optional being done right by a BIOS is an > illusion -- even mandatory things are screwed in many PC BIOSes. Indeed. Something I'm trying to convey to Eric, but I don't think he realises just how many pooched BIOSen there are out there. His conservative estimate of '150 entries in the blacklist' is possibly off by an order of 10 times or more. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:31 ` Dave Jones @ 2002-01-04 20:33 ` Eric S. Raymond 2002-01-04 20:56 ` Vojtech Pavlik ` (3 more replies) 0 siblings, 4 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-04 20:33 UTC (permalink / raw) To: Dave Jones Cc: Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List Dave Jones <davej@suse.de>: > Indeed. Something I'm trying to convey to Eric, but I don't think > he realises just how many pooched BIOSen there are out there. > His conservative estimate of '150 entries in the blacklist' > is possibly off by an order of 10 times or more. Are there even 1500 distinct PC motherboard designs in *existence*? :-) Think, Dave. The DMI standard dates from 1998. For there to be 1500 entries on the blacklist, someone would have to have been cranking out *500* PCI-capable, DMI-supporting motherboard designs a year each and every one of which lies about having ISA slots. This seems...implausible. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> It would be thought a hard government that should tax its people one tenth part. -- Benjamin Franklin ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:33 ` Eric S. Raymond @ 2002-01-04 20:56 ` Vojtech Pavlik 2002-01-04 20:57 ` Dave Jones ` (2 subsequent siblings) 3 siblings, 0 replies; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-04 20:56 UTC (permalink / raw) To: Eric S. Raymond, Dave Jones, Maciej W. Rozycki, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, Jan 04, 2002 at 03:33:05PM -0500, Eric S. Raymond wrote: > Dave Jones <davej@suse.de>: > > Indeed. Something I'm trying to convey to Eric, but I don't think > > he realises just how many pooched BIOSen there are out there. > > His conservative estimate of '150 entries in the blacklist' > > is possibly off by an order of 10 times or more. > > Are there even 1500 distinct PC motherboard designs in *existence*? :-) Definitely. And multiply that with BIOS revisions. > Think, Dave. The DMI standard dates from 1998. For there to be 1500 > entries on the blacklist, someone would have to have been cranking out > *500* PCI-capable, DMI-supporting motherboard designs a year each and > every one of which lies about having ISA slots. > > This seems...implausible. Not to me. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:33 ` Eric S. Raymond 2002-01-04 20:56 ` Vojtech Pavlik @ 2002-01-04 20:57 ` Dave Jones 2002-01-04 20:49 ` Eric S. Raymond 2002-01-04 21:04 ` Charles Cazabon 2002-01-05 17:28 ` Horst von Brand 3 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-04 20:57 UTC (permalink / raw) To: Eric S. Raymond Cc: Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Eric S. Raymond wrote: > Are there even 1500 distinct PC motherboard designs in *existence*? :-) > Think, Dave. The DMI standard dates from 1998. For there to be 1500 > entries on the blacklist, someone would have to have been cranking out > *500* PCI-capable, DMI-supporting motherboard designs a year each and > every one of which lies about having ISA slots. - Laptops. Lots of vendors, multiple product lines. - prebuilt systems with custom boards from Dell/Compaq. - The obvious motherboard vendors (ABit, Asus, Tyan, Soyo etc etc) - Vendor reference boards from AMD, VIA, SiS, ALi etc etc. - The seemingly endless cheap no-name boards from Taiwan. - Mulitple versions of BIOSen for all the above. Some with good DMI/some bad/some bad for different reasons etc. Still think that '150' systems sounds right ? Dell alone have probably achieved that in their product line over the last three years. And whilst DMI is a dying standard, its still present in a lot of new boxes, and will probably still continue to for some for a while. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:57 ` Dave Jones @ 2002-01-04 20:49 ` Eric S. Raymond 2002-01-04 21:08 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Eric S. Raymond @ 2002-01-04 20:49 UTC (permalink / raw) To: Dave Jones Cc: Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List Dave Jones <davej@suse.de>: > And whilst DMI is a dying standard, its still present in a lot of > new boxes, and will probably still continue to for some for a while. Waitaminute. DMI is a *dying* standard? What, if anything, is replacing it? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:49 ` Eric S. Raymond @ 2002-01-04 21:08 ` Dave Jones 2002-01-04 20:59 ` Eric S. Raymond 2002-01-04 21:17 ` David Woodhouse 0 siblings, 2 replies; 185+ messages in thread From: Dave Jones @ 2002-01-04 21:08 UTC (permalink / raw) To: Eric S. Raymond Cc: Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Eric S. Raymond wrote: > Dave Jones <davej@suse.de>: > > And whilst DMI is a dying standard, its still present in a lot of > > new boxes, and will probably still continue to for some for a while. > Waitaminute. DMI is a *dying* standard? What, if anything, is > replacing it? ACPI -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 21:08 ` Dave Jones @ 2002-01-04 20:59 ` Eric S. Raymond 2002-01-04 21:18 ` Dave Jones ` (2 more replies) 2002-01-04 21:17 ` David Woodhouse 1 sibling, 3 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-04 20:59 UTC (permalink / raw) To: Dave Jones Cc: Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List Dave Jones <davej@suse.de>: > > Waitaminute. DMI is a *dying* standard? What, if anything, is > > replacing it? > > ACPI OK. So can I ask ACPI if the board has ISA slots? Does it answer reliably? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The kind of charity you can force out of people nourishes about as much as the kind of love you can buy --- and spreads even nastier diseases. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:59 ` Eric S. Raymond @ 2002-01-04 21:18 ` Dave Jones 2002-01-04 21:23 ` Patrick Mochel 2002-01-05 0:13 ` Alan Cox 2 siblings, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-04 21:18 UTC (permalink / raw) To: Eric S. Raymond Cc: Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Eric S. Raymond wrote: > OK. So can I ask ACPI if the board has ISA slots? You can ask it what temperature your coffee pot is. It's an incredibly capable (some may say too capable). grab the spec and take a read (http://www.acpi.info iirc) > Does it answer reliably? Brings us back to.. "Can I trust a BIOS writer not to fsck things up" That, and ACPI support under Linux is still not-quite-there (but getting there). Coupled with Pat Mochels work with driverfs, we should eventually be able to get a complete enumerated tree of devices mountable somewhere. The only problem then, is that some boxes may not be running ACPI aware kernels, requiring you to parse the ACPI tables in userspace. (Not as easy as DMI, ACPI is a turing complete language requiring a bytecode (AML) parser) (Or you could just say fsck it if a acpi/driverfs aware kernel isn't present, which any sane person would) -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:59 ` Eric S. Raymond 2002-01-04 21:18 ` Dave Jones @ 2002-01-04 21:23 ` Patrick Mochel 2002-01-05 0:13 ` Alan Cox 2 siblings, 0 replies; 185+ messages in thread From: Patrick Mochel @ 2002-01-04 21:23 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Linux Kernel List On Fri, 4 Jan 2002, Eric S. Raymond wrote: > Dave Jones <davej@suse.de>: > > > Waitaminute. DMI is a *dying* standard? What, if anything, is > > > replacing it? > > > > ACPI > > OK. So can I ask ACPI if the board has ISA slots? Does it answer > reliably? The ACPI info comes from the BIOS. So, it's no more reliable than any other BIOS, and probably less so than ones that do/did DMI, as there are so many aspects to it. I would suggest reading the ACPI spec at http://acpi.info and the Intel implementation of it at http://developer.intel.com/technology/IAPC/acpi/index.htm for an idea of what it's supposed to do and what you can theoretically get from it. -pat ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:59 ` Eric S. Raymond 2002-01-04 21:18 ` Dave Jones 2002-01-04 21:23 ` Patrick Mochel @ 2002-01-05 0:13 ` Alan Cox 2 siblings, 0 replies; 185+ messages in thread From: Alan Cox @ 2002-01-05 0:13 UTC (permalink / raw) To: esr Cc: Dave Jones, Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton, Linux Kernel List > > ACPI > > OK. So can I ask ACPI if the board has ISA slots? Does it answer > reliably? On current evidence - no. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 21:08 ` Dave Jones 2002-01-04 20:59 ` Eric S. Raymond @ 2002-01-04 21:17 ` David Woodhouse 1 sibling, 0 replies; 185+ messages in thread From: David Woodhouse @ 2002-01-04 21:17 UTC (permalink / raw) To: esr Cc: Dave Jones, Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, Lionel Bouton, Linux Kernel List esr@thyrsus.com said: > OK. So can I ask ACPI if the board has ISA slots? Does it answer > reliably? Of course not. ACPI is done by BIOS engineers too, and hence has the same quality standards. -- dwmw2 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:33 ` Eric S. Raymond 2002-01-04 20:56 ` Vojtech Pavlik 2002-01-04 20:57 ` Dave Jones @ 2002-01-04 21:04 ` Charles Cazabon 2002-01-05 17:28 ` Horst von Brand 3 siblings, 0 replies; 185+ messages in thread From: Charles Cazabon @ 2002-01-04 21:04 UTC (permalink / raw) To: Linux Kernel List Cc: Eric S. Raymond, Dave Jones, Maciej W. Rozycki, Vojtech Pavlik, Alan Cox, David Woodhouse, Lionel Bouton Eric S. Raymond <esr@thyrsus.com> wrote: > Dave Jones <davej@suse.de>: > > Indeed. Something I'm trying to convey to Eric, but I don't think > > he realises just how many pooched BIOSen there are out there. > > His conservative estimate of '150 entries in the blacklist' > > is possibly off by an order of 10 times or more. > > Are there even 1500 distinct PC motherboard designs in *existence*? :-) There are tens of thousands of distinct PC motherboard designs in existence. I've personally worked on more than a thousand of them over the years. The big issue is that even with a single distinct design (say a reference design used by multiple manufacturers), there will be multiple differently-buggy BIOSen for that board before you even consider the different versions a single manufacturer will crank out over time. The motherboard market is a lot less diverse today than it was at its peak -- say late-486 through mid-Pentium (94-97 perhaps). At one point, there were a dozen major brands of core logic, and hundreds of motherboard manufacturers. Of course, DMI doesn't come into much of the older ones. Charles -- ----------------------------------------------------------------------- Charles Cazabon <linux@discworld.dyndns.org> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 20:33 ` Eric S. Raymond ` (2 preceding siblings ...) 2002-01-04 21:04 ` Charles Cazabon @ 2002-01-05 17:28 ` Horst von Brand 3 siblings, 0 replies; 185+ messages in thread From: Horst von Brand @ 2002-01-05 17:28 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Linux Kernel List "Eric S. Raymond" <esr@thyrsus.com> said: > Dave Jones <davej@suse.de>: > > Indeed. Something I'm trying to convey to Eric, but I don't think > > he realises just how many pooched BIOSen there are out there. > > His conservative estimate of '150 entries in the blacklist' > > is possibly off by an order of 10 times or more. > > Are there even 1500 distinct PC motherboard designs in *existence*? :-) Perhaps not, but there are at least 10 official revisions of the BIOS for this motherboard (intel sr440bx), and this is just one out of a few dozen intel has. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:04 ` Vojtech Pavlik 2002-01-04 19:05 ` Eric S. Raymond @ 2002-01-04 19:36 ` Maciej W. Rozycki 2002-01-04 19:45 ` Vojtech Pavlik 1 sibling, 1 reply; 185+ messages in thread From: Maciej W. Rozycki @ 2002-01-04 19:36 UTC (permalink / raw) To: Vojtech Pavlik Cc: Alan Cox, esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Vojtech Pavlik wrote: > And of course, there will be a huge amount of false positives, because > all the new chipsets have an ISA bridge built into the southbridge chip > and it is there even when no ISA slots are present. A false positive is less painful than a false negative. Then if a system has a PCI-ISA bridge, it's surely for purpose there (otherwise what is the justification for the additional cost of unused silicon?). Maybe for an on-board ISA serial or parallel port or an ISA floppy controller... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:36 ` Maciej W. Rozycki @ 2002-01-04 19:45 ` Vojtech Pavlik 2002-01-04 20:08 ` Maciej W. Rozycki 0 siblings, 1 reply; 185+ messages in thread From: Vojtech Pavlik @ 2002-01-04 19:45 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Alan Cox, esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, Jan 04, 2002 at 08:36:06PM +0100, Maciej W. Rozycki wrote: > On Fri, 4 Jan 2002, Vojtech Pavlik wrote: > > > And of course, there will be a huge amount of false positives, because > > all the new chipsets have an ISA bridge built into the southbridge chip > > and it is there even when no ISA slots are present. > > A false positive is less painful than a false negative. Then if a system > has a PCI-ISA bridge, it's surely for purpose there (otherwise what is the > justification for the additional cost of unused silicon?). Maybe for an > on-board ISA serial or parallel port or an ISA floppy controller... Because it's much cheaper to buy an off-the-shelf southbridge, even if you're not going to use the ISA bus for any devices if you're making an ISA-less mainboard, than trying to find or even design one without an ISA bridge in it. I recall people using the vt82c686a's with StrongARM CPUs even ... -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 19:45 ` Vojtech Pavlik @ 2002-01-04 20:08 ` Maciej W. Rozycki 0 siblings, 0 replies; 185+ messages in thread From: Maciej W. Rozycki @ 2002-01-04 20:08 UTC (permalink / raw) To: Vojtech Pavlik Cc: Alan Cox, esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Fri, 4 Jan 2002, Vojtech Pavlik wrote: > Because it's much cheaper to buy an off-the-shelf southbridge, even if > you're not going to use the ISA bus for any devices if you're making an > ISA-less mainboard, than trying to find or even design one without an > ISA bridge in it. Hmm, what exactly do you need a southbridge for in an ISA-less system? For IDE or USB you may use chips with no PCI-ISA bridge. They are likely to be cheaper, take less space on a PCB and consume less power. > I recall people using the vt82c686a's with StrongARM CPUs even ... Can't say anything about StrongARM boards, but it's possible they wire a serial port this way (not a rare device in the embedded world). OK, it is possible there are systems that have all the logic for an ISA bus but it's left unused. But given the insanity of the PC world, it's still better to ask user a few unneeded questions than to refuse to ask necessary ones. This also gives a user the chance to ask the vendor: "Why does your supposedly legacy-free system still contain an ISA device?" ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:09 ` Eric S. Raymond 2002-01-03 12:14 ` Alan Cox @ 2002-01-03 16:52 ` Rik van Riel 2002-01-03 17:01 ` Dave Jones 1 sibling, 1 reply; 185+ messages in thread From: Rik van Riel @ 2002-01-03 16:52 UTC (permalink / raw) To: Eric S. Raymond Cc: David Woodhouse, Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List On Thu, 3 Jan 2002, Eric S. Raymond wrote: > You have my intentions backwards. What I'd like to be able to do is > suppress ISA_SLOTS when there are detectably *no* ISA cards. So you want to make it impossible to compile kernels for old machines on the new fast machine standing next to it ? regards, Rik -- Shortwave goes a long way: irc.starchat.net #swl http://www.surriel.com/ http://distro.conectiva.com/ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 16:52 ` Rik van Riel @ 2002-01-03 17:01 ` Dave Jones 2002-01-03 17:27 ` Eric S. Raymond 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-03 17:01 UTC (permalink / raw) To: Rik van Riel Cc: Eric S. Raymond, David Woodhouse, Lionel Bouton, Alan Cox, Linux Kernel List On Thu, 3 Jan 2002, Rik van Riel wrote: > > You have my intentions backwards. What I'd like to be able to do is > > suppress ISA_SLOTS when there are detectably *no* ISA cards. > So you want to make it impossible to compile kernels for > old machines on the new fast machine standing next to it ? I assumed ESR proposed a 'configure for this box' button, not the default case. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 17:01 ` Dave Jones @ 2002-01-03 17:27 ` Eric S. Raymond 0 siblings, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 17:27 UTC (permalink / raw) To: Dave Jones Cc: Rik van Riel, David Woodhouse, Lionel Bouton, Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > > > You have my intentions backwards. What I'd like to be able to do is > > > suppress ISA_SLOTS when there are detectably *no* ISA cards. > > So you want to make it impossible to compile kernels for > > old machines on the new fast machine standing next to it ? > > I assumed ESR proposed a 'configure for this box' button, > not the default case. Exactly. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:14 ` David Woodhouse 2002-01-03 9:09 ` Eric S. Raymond @ 2002-01-03 9:24 ` David Woodhouse 1 sibling, 0 replies; 185+ messages in thread From: David Woodhouse @ 2002-01-03 9:24 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List esr@thyrsus.com said: > You have my intentions backwards. What I'd like to be able to do is > suppress ISA_SLOTS when there are detectably *no* ISA cards. > Unfortunately I have had it demonstrated that the DMI tables can give > false negatives (false positives would not have been a showstopper). I suggest you just suppress it anyway unless you're in normal configuration mode. As you say - you don't need to care too much about ancient hardware, and if they have ISA cards they're going to _need_ to know what's in the box anyway. -- dwmw2 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 2:10 ` Eric S. Raymond 2002-01-03 2:44 ` Dave Jones @ 2002-01-03 14:12 ` Horst von Brand 1 sibling, 0 replies; 185+ messages in thread From: Horst von Brand @ 2002-01-03 14:12 UTC (permalink / raw) To: Eric S. Raymond, Linux Kernel List "Eric S. Raymond" <esr@thyrsus.com> said: > Dave Jones <davej@suse.de>: [...] > > And if you don't know what hardware you've got in the box your > > configuring a kernel for, its questionable that you should be > > doing so in the first place. > > That's exactly the bad assumption we need to dynamite. Vaporize. Nuke. Just why is it a bad assumption? > It should be possible to build a correctly customized kernel without > opening the case of your machine. It should be possible for > non-technical people to customize kernels. Kernel customization > should present an interface based on what you want to *do* with the > machine, not the specific hardware inside it (because the configurator > is smart enough to map from the intended-function domain to the hardware- > specifics domain). Customized kernels for what? Your end-user will (or should be at least) quite happy with the vendor kernel. It is not the times anymore where you had to compile a custom kernel for each machine because there were no modules, and RAM (and even disk space) was dear. Your customized kernel for Aunt Tillie (if she wants to compile a kernel) would be more along the lines of a distribution kernel, with everything possible build as modules. I think this kind of user would be quite confused if the kernel build on Uncle Adam's machine doesn't work on Aunt Tillie's. > Think useability. On Macintoshes, you configure a kernel by moving the > equivalents of modules in and out of a system folder. Users tune their > kernels by moving files around -- no muttering of elaborate incantations > required. *That's* the direction we should be moving in; there is no > good technical reason for the process to be anywhere near as arcane as > it is now. On Linux, you modprobe/rmmod them. Nice and easy. Or let automagic take over the loading/unloading. Works for millions of distribution <foo> users. > I have spent eighteen months thinking very hard about this problem, and > whacking a significant piece of it with actual code. So I can say this: > the reason linux kernel configuration is still a black art is *only* > that lots of people *want it to be that way*. We have elected to > treat kernel-building as an initiatory rite that separates the worthy > geeks from the unwashed technopeasant masses. That something _can_ be done, and would look *way* cool, doesn't make it worthwhile in day-to-day use. Just think on _who_ the users of this would be, and exactly what problems for them it would solve. Aunt Tillie doesn't build kernels; if she did she'd prefer to build a kernel that works everywhere. No magic "build a kernel that will _only_ run here_" wellcome, give her an all-modules .config for starters. Uncle Alan builds kernels for a living, he does very well know what he wants and what the machine's inards are. No handholding needed either. Sure, it would be nice to go to a random machine and find out what it has inside without opening it. But that is a niche application, and given the horrible (and ever changing) mess of PC hardware, it is probably hard to get even 80% right, where for your Aunt Tillie configuration system you require 100% accuracy. BTW, you say "kernel configuration is a black art because we want it to stay that way". It isn't, really (I've gotten unwashed users configure kernels with menuconfig after a short shower, so it is not _that_ bad), and little in Linux fails to happen because Ye Gods Forbade Doing It: If it really was as bad as you say, the pressure to get an easier kernel configuration system would be quite large. This pressure gave us "make configure" from the original "edit this funky file, just make sure not to screw up", and progressed to "make menuconfig" and its ilk with random order selections. In terms of user interface not much more seems to be needed, as little (if any) real pressure to change this has been seen in many years. I dimly remember mechanisms for autodetection and .configure autobuilding, they never got far. Either because it isn't really needed, or because it is (or was) just too hard to get it right enough for real use. I'd think both are partly responsible. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:10 ` Dave Jones 2002-01-03 2:10 ` Eric S. Raymond @ 2002-01-03 3:07 ` Greg Hennessy 2002-01-03 9:08 ` David Woodhouse 2002-01-03 10:34 ` Kai Henningsen 3 siblings, 0 replies; 185+ messages in thread From: Greg Hennessy @ 2002-01-03 3:07 UTC (permalink / raw) To: linux-kernel In article <Pine.LNX.4.33.0201030006120.427-100000@Appserv.suse.de>, Dave Jones <davej@suse.de> wrote: > And if you don't know what hardware you've got in the box your > configuring a kernel for, its questionable that you should be > doing so in the first place. I admister machines that are old enough I've forgotten what hardware they have in them. :) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:10 ` Dave Jones 2002-01-03 2:10 ` Eric S. Raymond 2002-01-03 3:07 ` Greg Hennessy @ 2002-01-03 9:08 ` David Woodhouse 2002-01-03 9:03 ` Eric S. Raymond 2002-01-03 9:19 ` David Woodhouse 2002-01-03 10:34 ` Kai Henningsen 3 siblings, 2 replies; 185+ messages in thread From: David Woodhouse @ 2002-01-03 9:08 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List esr@thyrsus.com said: > Think useability. On Macintoshes, you configure a kernel by moving > the equivalents of modules in and out of a system folder. Users tune > their kernels by moving files around -- no muttering of elaborate > incantations required. *That's* the direction we should be moving in; > there is no good technical reason for the process to be anywhere near > as arcane as it is now. We have it better than that already. The distro vendor provides all the modules and they're automatically loaded on demand - you don't even need to move them into the system folder. -- dwmw2 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:08 ` David Woodhouse @ 2002-01-03 9:03 ` Eric S. Raymond 2002-01-03 12:20 ` Alan Cox 2002-01-03 9:19 ` David Woodhouse 1 sibling, 1 reply; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 9:03 UTC (permalink / raw) To: David Woodhouse; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List David Woodhouse <dwmw2@infradead.org>: > > Think useability. On Macintoshes, you configure a kernel by moving > > the equivalents of modules in and out of a system folder. Users tune > > their kernels by moving files around -- no muttering of elaborate > > incantations required. *That's* the direction we should be moving in; > > there is no good technical reason for the process to be anywhere near > > as arcane as it is now. > > We have it better than that already. The distro vendor provides all the > modules and they're automatically loaded on demand - you don't even need to > move them into the system folder. So you're saying the users should be completely lost any time they want to use an upated kernel? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:03 ` Eric S. Raymond @ 2002-01-03 12:20 ` Alan Cox 2002-01-03 12:07 ` BALBIR SINGH 2002-01-03 12:56 ` Urban Widmark 0 siblings, 2 replies; 185+ messages in thread From: Alan Cox @ 2002-01-03 12:20 UTC (permalink / raw) To: esr; +Cc: David Woodhouse, Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List > So you're saying the users should be completely lost any time they want > to use an upated kernel? Quite honestly if you want a user built "update" kernel it should probably work out the critical stuff (CPU, memory size limit, SMP) set a few things to safe values, and build all the driver modules. Why ask the user at all. The boot process already knows what modules to load Instead you get Checking... This is an X86 platform You have an AMD K6 processor Your machine lacks SMP support You have 256Mb of memory I am building you a kernel for an AMD K6 series processor with up to 1Gb of memory and no SMP. If you add more than 1Gb of memory you will need to build a new kernel Alan ^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: ISA slot detection on PCI systems? 2002-01-03 12:20 ` Alan Cox @ 2002-01-03 12:07 ` BALBIR SINGH 2002-01-03 12:40 ` Alan Cox 2002-01-03 12:56 ` Urban Widmark 1 sibling, 1 reply; 185+ messages in thread From: BALBIR SINGH @ 2002-01-03 12:07 UTC (permalink / raw) To: Alan Cox, esr Cc: David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List [-- Attachment #1: Type: text/plain, Size: 1050 bytes --] |> So you're saying the users should be completely lost any time they want |> to use an upated kernel? | |Quite honestly if you want a user built "update" kernel it should probably |work out the critical stuff (CPU, memory size limit, SMP) set a few things |to safe values, and build all the driver modules. | |Why ask the user at all. The boot process already knows what |modules to load |Instead you get | | Checking... | This is an X86 platform | You have an AMD K6 processor | Your machine lacks SMP support | You have 256Mb of memory | | I am building you a kernel for an AMD K6 series processor with | up to 1Gb of memory and no SMP. If you add more than 1Gb of memory | you will need to build a new kernel This would break things like cross-compilation. Not sure how many people use it though. You will have to be on the machine for which you intend to compile the kernel. If you are compiling the kernel for the same machine then it is the best thing to happen, provided the software doing the configuration for u is not broken Balbir [-- Attachment #2: Wipro_Disclaimer.txt --] [-- Type: text/plain, Size: 855 bytes --] ----------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ------------------------------------------------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:07 ` BALBIR SINGH @ 2002-01-03 12:40 ` Alan Cox 2002-01-03 21:44 ` Lionel Bouton 0 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-03 12:40 UTC (permalink / raw) To: BALBIR SINGH Cc: Alan Cox, esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List > This would break things like cross-compilation. Not sure how many people > use it though. You will have to be on the machine for which you intend > to compile the kernel. If you are compiling the kernel for the same machine > then it is the best thing to happen, provided the software doing the > configuration for u is not broken I'm really not too worried about Grandma cross compiling kernels ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:40 ` Alan Cox @ 2002-01-03 21:44 ` Lionel Bouton 2002-01-03 22:17 ` David Weinehall ` (2 more replies) 0 siblings, 3 replies; 185+ messages in thread From: Lionel Bouton @ 2002-01-03 21:44 UTC (permalink / raw) To: Alan Cox Cc: BALBIR SINGH, esr, David Woodhouse, Dave Jones, Linux Kernel List Alan Cox wrote: >>This would break things like cross-compilation. Not sure how many people >>use it though. You will have to be on the machine for which you intend >>to compile the kernel. If you are compiling the kernel for the same machine >>then it is the best thing to happen, provided the software doing the >>configuration for u is not broken >> > > I'm really not too worried about Grandma cross compiling kernels ROTFL at the mental image of my Grandma configuring a cross-compiling environment. Eric, you said somewhere else in this thread that eventually we should be able to make kernel configuration as easy as MAC configuration. In short we can't. MAC configuration is a dream we can't touch. The core hardware and most importantly the mainboard firmware is done by the very same company that develops the OS. I guess they didn't shout themselves in the feet and made firmware and hardware with clean enough interfaces that they could make hardware detection trivial. Even if they did mistakes, had bugs, they have the exhaustive list of them and most probably can easily use workarounds. Contrast this with the PC world : numerous mainboard manufacturers, bios developpers, extension card manufacturers, Operating Systems, each with their own bugs others desesperately try to work around... The general case where all works ok (no bugs in dmi, pnp, ...) is the exception and the land here is full of workarounds and dead ends if you want to do hardware detection. The worst case : the plain old ISA bus where you can't try to detect a specific extansion card without risking to lock the system hard by screwing some other type that is listening on ports you probed. What I think we should try is to identify the most stable interfaces (lspci works ok for most systems and would be of great help), use them and let the user fill the gap (ISA/MCA/VLB/AGP bus switches for the *user* is a great idea indeed). We are quite PC centric here. But other archs are certainly far more friendly to what you're up to. LB. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 21:44 ` Lionel Bouton @ 2002-01-03 22:17 ` David Weinehall 2002-01-04 18:41 ` Maciej W. Rozycki 2002-01-03 22:36 ` Alan Cox 2002-01-04 12:10 ` Alex 2 siblings, 1 reply; 185+ messages in thread From: David Weinehall @ 2002-01-03 22:17 UTC (permalink / raw) To: Lionel Bouton Cc: Alan Cox, BALBIR SINGH, esr, David Woodhouse, Dave Jones, Linux Kernel List On Thu, Jan 03, 2002 at 10:44:57PM +0100, Lionel Bouton wrote: > Alan Cox wrote: > > >>This would break things like cross-compilation. Not sure how many people > >>use it though. You will have to be on the machine for which you intend > >>to compile the kernel. If you are compiling the kernel for the same machine > >>then it is the best thing to happen, provided the software doing the > >>configuration for u is not broken > >> > > > > I'm really not too worried about Grandma cross compiling kernels > > > ROTFL at the mental image of my Grandma configuring a cross-compiling > environment. > > Eric, you said somewhere else in this thread that eventually we should > be able to make kernel configuration as easy as MAC configuration. > > In short we can't. > > MAC configuration is a dream we can't touch. The core hardware and most > importantly the mainboard firmware is done by the very same company that > develops the OS. I guess they didn't shout themselves in the feet and > made firmware and hardware with clean enough interfaces that they could > make hardware detection trivial. > Even if they did mistakes, had bugs, they have the exhaustive list of > them and most probably can easily use workarounds. > > Contrast this with the PC world : numerous mainboard manufacturers, bios > developpers, extension card manufacturers, Operating Systems, each with > their own bugs others desesperately try to work around... > > The general case where all works ok (no bugs in dmi, pnp, ...) is the > exception and the land here is full of workarounds and dead ends if you > want to do hardware detection. > > The worst case : the plain old ISA bus where you can't try to detect a > specific extansion card without risking to lock the system hard by > screwing some other type that is listening on ports you probed. > > What I think we should try is to identify the most stable interfaces > (lspci works ok for most systems and would be of great help), use them > and let the user fill the gap (ISA/MCA/VLB/AGP bus switches for the > *user* is a great idea indeed). > > We are quite PC centric here. But other archs are certainly far more > friendly to what you're up to. At least MCA and NuBus can be autodetected, and I'm fairly confident the people behind the VME-bus and TurboChannel weren't stupid either, so those can probably be autodetected and probed too. Dunno about VLB, but AGP is sort of a special-case of PCI (if I'm not all wrong) and can be autodtected too. ISA, on the other hand, is always a gamble. I bet there are other exceptions as well. /David Weinehall _ _ // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 22:17 ` David Weinehall @ 2002-01-04 18:41 ` Maciej W. Rozycki 0 siblings, 0 replies; 185+ messages in thread From: Maciej W. Rozycki @ 2002-01-04 18:41 UTC (permalink / raw) To: David Weinehall Cc: Lionel Bouton, Alan Cox, BALBIR SINGH, esr, David Woodhouse, Dave Jones, Linux Kernel List On Thu, 3 Jan 2002, David Weinehall wrote: > At least MCA and NuBus can be autodetected, and I'm fairly confident > the people behind the VME-bus and TurboChannel weren't stupid either, > so those can probably be autodetected and probed too. The TURBOchannel is currently DECstation-only, so it can be easily deduced by the system type from /proc/cpuinfo (Alphas have it there as well, so if the Alpha port is ever finished there should be no problem). You can have a Qbus-TURBOchannel bridge on certain VAX systems, so it would have to be detected separately once (if) supported. I'm not sure if it's worthwhile to implement /proc/bus/tc or whatever as there is likely nothing in the userland to need that info ever and for diagnostics the firmware and the startup log are sufficient. If useful, it would be trivial to code, though. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 21:44 ` Lionel Bouton 2002-01-03 22:17 ` David Weinehall @ 2002-01-03 22:36 ` Alan Cox 2002-01-04 12:10 ` Alex 2 siblings, 0 replies; 185+ messages in thread From: Alan Cox @ 2002-01-03 22:36 UTC (permalink / raw) To: Lionel Bouton Cc: Alan Cox, BALBIR SINGH, esr, David Woodhouse, Dave Jones, Linux Kernel List > What I think we should try is to identify the most stable interfaces > (lspci works ok for most systems and would be of great help), use them > and let the user fill the gap (ISA/MCA/VLB/AGP bus switches for the > *user* is a great idea indeed). Most of the PC stuff is doable. If you doubt that run a Red Hat 7.2 install and simply keep hitting the default options 8) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 21:44 ` Lionel Bouton 2002-01-03 22:17 ` David Weinehall 2002-01-03 22:36 ` Alan Cox @ 2002-01-04 12:10 ` Alex 2002-01-04 12:20 ` Dave Jones 2 siblings, 1 reply; 185+ messages in thread From: Alex @ 2002-01-04 12:10 UTC (permalink / raw) To: linux-kernel On Thu, 3 Jan 2002, Lionel Bouton wrote: > MAC configuration is a dream we can't touch. I just had an idea in case what we might do in case of complex hardware.... We already have the "command line parameter" that we can provide to the kernel. Maybe the best thing would be to supply the kernel a "large" _textfile_ with all the hardware the user definitely has (at such-and such irq/dma/io); the textfile could be the output resilt from a "userfriendly" hardware-detection tool that lists all categories of hardwares etc. and has - generally - a large hardware database. What do you think? Yours, Alex ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 12:10 ` Alex @ 2002-01-04 12:20 ` Dave Jones 2002-01-04 12:22 ` Alex 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-04 12:20 UTC (permalink / raw) To: Alex; +Cc: linux-kernel On Fri, 4 Jan 2002, Alex wrote: > Maybe the best thing would be to supply the kernel a "large" _textfile_ > with all the hardware the user definitely has (at such-and such > irq/dma/io); the textfile could be the output resilt from a > "userfriendly" hardware-detection tool that lists all categories of > hardwares etc. and has - generally - a large hardware database. Think about ancient hardware (Yes theres lots of it still in use) These beasts had jumpers to set IRQ/DMA etc, and this was not detectable from software until PNPISA arrived on the scene. You're still going to need user interaction for a lot of these. "But Microsoft doesn't" isn't an argument any more either, they dropped support for really ancient hardware a long time ago. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 12:20 ` Dave Jones @ 2002-01-04 12:22 ` Alex 2002-01-04 12:30 ` Dave Jones 0 siblings, 1 reply; 185+ messages in thread From: Alex @ 2002-01-04 12:22 UTC (permalink / raw) To: Dave Jones; +Cc: linux-kernel On Fri, 4 Jan 2002, Dave Jones wrote: > On Fri, 4 Jan 2002, Alex wrote: > > > Maybe the best thing would be to supply the kernel a "large" _textfile_ > > with all the hardware the user definitely has (at such-and such > > irq/dma/io); the textfile could be the output resilt from a > > "userfriendly" hardware-detection tool that lists all categories of > > hardwares etc. and has - generally - a large hardware database. > > Think about ancient hardware (Yes theres lots of it still in use) > These beasts had jumpers to set IRQ/DMA etc, and this was not detectable > from software until PNPISA arrived on the scene. > > You're still going to need user interaction for a lot of these. That is why I recommended that the textfile is the output of an interactive hardware-detection tool. Yes, interactive. :-) > "But Microsoft doesn't" isn't an argument any more either, they dropped > support for really ancient hardware a long time ago. Show them that we can do better. :-D Alex ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 12:22 ` Alex @ 2002-01-04 12:30 ` Dave Jones 2002-01-04 12:47 ` Alex 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-04 12:30 UTC (permalink / raw) To: Alex; +Cc: linux-kernel On Fri, 4 Jan 2002, Alex wrote: > > You're still going to need user interaction for a lot of these. > That is why I recommended that the textfile is the output of an > interactive hardware-detection tool. Yes, interactive. :-) vim /etc/modules.conf is about as interactive as it gets. If you want pointy clicky user interfaces for this, pretty much every distro has one these days. > > "But Microsoft doesn't" isn't an argument any more either, they dropped > > support for really ancient hardware a long time ago. > Show them that we can do better. :-D On ancient hardware, we win, no contest. We're doing pretty good with modern hardware also except for a few special cases. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-04 12:30 ` Dave Jones @ 2002-01-04 12:47 ` Alex 0 siblings, 0 replies; 185+ messages in thread From: Alex @ 2002-01-04 12:47 UTC (permalink / raw) To: Dave Jones; +Cc: linux-kernel On Fri, 4 Jan 2002, Dave Jones wrote: > On Fri, 4 Jan 2002, Alex wrote: > > > > You're still going to need user interaction for a lot of these. > > That is why I recommended that the textfile is the output of an > > interactive hardware-detection tool. Yes, interactive. :-) > > vim /etc/modules.conf > is about as interactive as it gets. Modules.conf is not all there is. What if modules.conf resides on an scsi-harddisk with an scsi controller who is just making the problem of ancient hardware in the first case ? etc.etc. You are running around with the underlying assumption that you can - indeed - *acess* modules.conf via *already detected* hardware. This is not the same assumption my textfile example operates from. My textfile-for-kernel operates from the assumption that *almost nothing whatsoever* on hardware is "fixed compiled" in the kernel at the moment we're talking about it, and that the precompiled modules will probably be loaded from the distro cd etc.... Later, Alex ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 12:20 ` Alan Cox 2002-01-03 12:07 ` BALBIR SINGH @ 2002-01-03 12:56 ` Urban Widmark 1 sibling, 0 replies; 185+ messages in thread From: Urban Widmark @ 2002-01-03 12:56 UTC (permalink / raw) To: Alan Cox; +Cc: esr, David Woodhouse, Dave Jones, Lionel Bouton, Linux Kernel List On Thu, 3 Jan 2002, Alan Cox wrote: > > So you're saying the users should be completely lost any time they want > > to use an upated kernel? > > Quite honestly if you want a user built "update" kernel it should probably > work out the critical stuff (CPU, memory size limit, SMP) set a few things > to safe values, and build all the driver modules. If the previous config is saved automatically that could be used and do an oldconfig as the autoconfig. kbuild 2.5 has /lib/modules/`uname -r`/.config ? the old idea of appending config.gz to the kernel image /etc/defkernel.config ... If this is for people doing updates I can't imagine anything better than using the existing config as a base. Even if the config is a vendor config and they are now building a non-vendor kernel. That would help people from turning off things they (think they) don't need but that their init scripts assume is there. Things you can't autodetect. The first step from vendor kernel to a custom one will mean that a few options are no longer vaild, but that shouldn't be a problem for oldconfig. Or perhaps do both, get the old config as base, then autodetect the hardware you can find. Any new options are set to on or off based on the detected hardware. After that you let the user turn things on and off. If the user tries to turn off something that you know he has in the box give a big warning ("Are you sure you want to disable IDE? I can see that you have both an IDE HD and CD-ROM. This behaviour is inconsistent with logic." :) All of this is of course for the "Aunt Tilly" mode only. (make tillyconfig? :) /Urban ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:08 ` David Woodhouse 2002-01-03 9:03 ` Eric S. Raymond @ 2002-01-03 9:19 ` David Woodhouse 2002-01-03 9:12 ` Eric S. Raymond 2002-01-03 9:31 ` David Woodhouse 1 sibling, 2 replies; 185+ messages in thread From: David Woodhouse @ 2002-01-03 9:19 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List esr@thyrsus.com said: > So you're saying the users should be completely lost any time they > want to use an upated kernel? Not at all - that's what up2date is for. If I want something newer than the latest certified erratum release from some vendor with a clue, then I probably ought to know what I'm doing. Making it _easier_ for Aunt Tillie to install something like 2.4.10 is not necessarily doing her a favour. -- dwmw2 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:19 ` David Woodhouse @ 2002-01-03 9:12 ` Eric S. Raymond 2002-01-03 9:31 ` David Woodhouse 1 sibling, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 9:12 UTC (permalink / raw) To: David Woodhouse; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List David Woodhouse <dwmw2@infradead.org>: > Not at all - that's what up2date is for. If I want something newer than the > latest certified erratum release from some vendor with a clue, then I > probably ought to know what I'm doing. OK. There are enough real barriers tere. Why leave artificial ones in place? > Making it _easier_ for Aunt Tillie to install something like 2.4.10 is not > necessarily doing her a favour. But making it unnecessarily harder is *certainly* not a favor. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Faith may be defined briefly as an illogical belief in the occurrence of the improbable...A man full of faith is simply one who has lost (or never had) the capacity for clear and realistic thought. He is not a mere ass: he is actually ill. -- H. L. Mencken ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 9:19 ` David Woodhouse 2002-01-03 9:12 ` Eric S. Raymond @ 2002-01-03 9:31 ` David Woodhouse 1 sibling, 0 replies; 185+ messages in thread From: David Woodhouse @ 2002-01-03 9:31 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List esr@thyrsus.com said: > > Making it _easier_ for Aunt Tillie to install something like 2.4.10 is > > not necessarily doing her a favour. > But making it unnecessarily harder is *certainly* not a favor. Making it _gratuitously_ harder isn't called for, true - but it's definitely not a case we need to _optimise_ for. I'm surprised you feel the need to do it, but I'll not try and stop you - as long as in doing so you don't make it more difficult for the people who _do_ actually do this all day every day. -- dwmw2 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:10 ` Dave Jones ` (2 preceding siblings ...) 2002-01-03 9:08 ` David Woodhouse @ 2002-01-03 10:34 ` Kai Henningsen 2002-01-03 14:42 ` Dave Jones 3 siblings, 1 reply; 185+ messages in thread From: Kai Henningsen @ 2002-01-03 10:34 UTC (permalink / raw) To: linux-kernel davej@suse.de (Dave Jones) wrote on 03.01.02 in <Pine.LNX.4.33.0201030006120.427-100000@Appserv.suse.de>: > And if you don't know what hardware you've got in the box your > configuring a kernel for, its questionable that you should be > doing so in the first place. IME, not knowing that exactly is the rule rather than the exception. There's a reason we have autodetect code in all sorts of software, including the Linux kernel. Now, if we cannot reliably autodetect hardware, we should always make it possible to override this manually, and maybe also inform the user that we're not certain. But that's no excuse not to try to autodetect when the user has *not* overridden us. MfG Kai ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 10:34 ` Kai Henningsen @ 2002-01-03 14:42 ` Dave Jones 2002-01-04 15:39 ` Kai Henningsen 0 siblings, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-03 14:42 UTC (permalink / raw) To: Kai Henningsen; +Cc: linux-kernel On 3 Jan 2002, Kai Henningsen wrote: > Now, if we cannot reliably autodetect hardware, we should always make it > possible to override this manually, and maybe also inform the user that > we're not certain. But that's no excuse not to try to autodetect when the > user has *not* overridden us. Autodetecting non-pnp ISA hardware safely is something of a black art. Numerous drivers just hang if you load them and the card isn't present, or there's another card which answers on the same port/address. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-03 14:42 ` Dave Jones @ 2002-01-04 15:39 ` Kai Henningsen 0 siblings, 0 replies; 185+ messages in thread From: Kai Henningsen @ 2002-01-04 15:39 UTC (permalink / raw) To: linux-kernel davej@suse.de (Dave Jones) wrote on 03.01.02 in <Pine.LNX.4.33.0201031540390.7309-100000@Appserv.suse.de>: > On 3 Jan 2002, Kai Henningsen wrote: > > > Now, if we cannot reliably autodetect hardware, we should always make it > > possible to override this manually, and maybe also inform the user that > > we're not certain. But that's no excuse not to try to autodetect when the > > user has *not* overridden us. > > Autodetecting non-pnp ISA hardware safely is something of a black art. > Numerous drivers just hang if you load them and the card isn't present, > or there's another card which answers on the same port/address. Well yes, that's why I asked for the override and the warning. MfG Kai ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:48 ` Eric S. Raymond 2002-01-02 23:10 ` Dave Jones @ 2002-01-02 23:15 ` Alan Cox 2002-01-02 23:07 ` Eric S. Raymond 2002-01-02 23:19 ` Mike Castle ` (2 subsequent siblings) 4 siblings, 1 reply; 185+ messages in thread From: Alan Cox @ 2002-01-02 23:15 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Lionel Bouton, Alan Cox, Linux Kernel List > (Telling me to rely on dmidecode already being installed SUID is not > a good answer either. No prizes for figuring out why.) Well you can't rely on the kernel having the modification either. I guess you'll just have to guess. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:15 ` Alan Cox @ 2002-01-02 23:07 ` Eric S. Raymond 2002-01-02 23:33 ` Lionel Bouton 0 siblings, 1 reply; 185+ messages in thread From: Eric S. Raymond @ 2002-01-02 23:07 UTC (permalink / raw) To: Alan Cox; +Cc: Dave Jones, Lionel Bouton, Linux Kernel List Alan Cox <alan@lxorguk.ukuu.org.uk>: > > (Telling me to rely on dmidecode already being installed SUID is not > > a good answer either. No prizes for figuring out why.) > > Well you can't rely on the kernel having the modification either. If /proc/dmi were to go in soon, at least I *could* rely on it in 2.6. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Live free or die; death is not the worst of evils. -- General George Stark. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:07 ` Eric S. Raymond @ 2002-01-02 23:33 ` Lionel Bouton 2002-01-02 23:37 ` Dave Jones 2002-01-03 2:17 ` Eric S. Raymond 0 siblings, 2 replies; 185+ messages in thread From: Lionel Bouton @ 2002-01-02 23:33 UTC (permalink / raw) To: esr; +Cc: Alan Cox, Dave Jones, Linux Kernel List Eric S. Raymond wrote: > Alan Cox <alan@lxorguk.ukuu.org.uk>: > >>>(Telling me to rely on dmidecode already being installed SUID is not >>>a good answer either. No prizes for figuring out why.) >>> >>Well you can't rely on the kernel having the modification either. >> > > If /proc/dmi were to go in soon, at least I *could* rely on it in 2.6. > If in rc.sysinit a call to "dmidecode > /var/run/dmi" were to go in the user space 2.6 kernel build dependancies in Documentation/Changes, you'll be on the same level. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:33 ` Lionel Bouton @ 2002-01-02 23:37 ` Dave Jones 2002-01-03 2:19 ` Eric S. Raymond 2002-01-03 2:17 ` Eric S. Raymond 1 sibling, 1 reply; 185+ messages in thread From: Dave Jones @ 2002-01-02 23:37 UTC (permalink / raw) To: Lionel Bouton; +Cc: esr, Alan Cox, Linux Kernel List On Thu, 3 Jan 2002, Lionel Bouton wrote: > > If /proc/dmi were to go in soon, at least I *could* rely on it in 2.6. > If in rc.sysinit a call to "dmidecode > /var/run/dmi" were to go in the > user space 2.6 kernel build dependancies in Documentation/Changes, > you'll be on the same level. Could even be done as part of Al's early-userspace, thus removing the reliance upon vendors to do it. Does imply that you're building 2.6 on a 2.6 enabled distro though. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:37 ` Dave Jones @ 2002-01-03 2:19 ` Eric S. Raymond 0 siblings, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 2:19 UTC (permalink / raw) To: Dave Jones; +Cc: Lionel Bouton, Alan Cox, Linux Kernel List Dave Jones <davej@suse.de>: > On Thu, 3 Jan 2002, Lionel Bouton wrote: > > > > If /proc/dmi were to go in soon, at least I *could* rely on it in 2.6. > > If in rc.sysinit a call to "dmidecode > /var/run/dmi" were to go in the > > user space 2.6 kernel build dependancies in Documentation/Changes, > > you'll be on the same level. > > Could even be done as part of Al's early-userspace, thus removing the > reliance upon vendors to do it. Does imply that you're building 2.6 on a > 2.6 enabled distro though. Tell me more. This begins to sound potentially interesting -- I can certainly live with knowing the state of the DMI tables as of the time of last boot, as long as it's in a fixed location that the autoconfigurator can count on. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Gun Control: The theory that a woman found dead in an alley, raped and strangled with her panty hose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound. -- L. Neil Smith ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:33 ` Lionel Bouton 2002-01-02 23:37 ` Dave Jones @ 2002-01-03 2:17 ` Eric S. Raymond 1 sibling, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 2:17 UTC (permalink / raw) To: Lionel Bouton; +Cc: Alan Cox, Dave Jones, Linux Kernel List Lionel Bouton <Lionel.Bouton@free.fr>: > If in rc.sysinit a call to "dmidecode > /var/run/dmi" were to go in the > user space 2.6 kernel build dependancies in Documentation/Changes, > you'll be on the same level. Problem is that would create another external dependency for the kernel configuration process. Unless you're proposing that dmidecode would live with the kernel sources and get installed with them. But I sense there might be the beginnings of a solution here... -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> 'Faith' means not _wanting_ to know what is true. -- Nietzsche, Der Antichrist ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:48 ` Eric S. Raymond 2002-01-02 23:10 ` Dave Jones 2002-01-02 23:15 ` Alan Cox @ 2002-01-02 23:19 ` Mike Castle 2002-01-02 23:23 ` Lionel Bouton 2002-01-05 7:05 ` H. Peter Anvin 4 siblings, 0 replies; 185+ messages in thread From: Mike Castle @ 2002-01-02 23:19 UTC (permalink / raw) To: Linux Kernel List; +Cc: Eric S. Raymond, Dave Jones, Lionel Bouton, Alan Cox On Wed, Jan 02, 2002 at 05:48:24PM -0500, Eric S. Raymond wrote: > But a setuid program *will not solve my problem*. It does NOT have to be setuid. su echo 'dmidecode > /var/run/dmi' >> /etc/init.d/bootmisc.sh And reboot once (or run the command by hand). mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:48 ` Eric S. Raymond ` (2 preceding siblings ...) 2002-01-02 23:19 ` Mike Castle @ 2002-01-02 23:23 ` Lionel Bouton 2002-01-02 23:44 ` Mike Castle 2002-01-03 2:20 ` Eric S. Raymond 2002-01-05 7:05 ` H. Peter Anvin 4 siblings, 2 replies; 185+ messages in thread From: Lionel Bouton @ 2002-01-02 23:23 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Alan Cox, Linux Kernel List Eric S. Raymond wrote: > [...] > The person running the autoconfigurator is not and should not be doing so > as root. Requiring the person to stop and sun sudo just so the > autoconfigurator can proceed is exactly the sort of pointless > obstacle we should *not* be putting in front of users! > > (Telling me to rely on dmidecode already being installed SUID is not > a good answer either. No prizes for figuring out why.) > > Ay caramba...please guys, try get your heads out of the internals > and start thinking from the *useability* angle for once! > Eric I see your point now. But stop me if I don't get the idea behind your autoconfigurator : Guessing the hardware configuration is done in order to ease the whole configuration process. After polishing the configuration - no need for root priviledge - the user start the build process that doesn't need root priviledge either. But when the user gets the resulting kernel how does (s)he avoid suing to root in order to *install* it and its modules ? I'm not familiar with people configuring and compiling kernels for pleasure. They usually want to boot it... Your whole point here is not to avoid several su instead of 1? LB. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:23 ` Lionel Bouton @ 2002-01-02 23:44 ` Mike Castle 2002-01-03 0:11 ` Lionel Bouton 2002-01-03 2:20 ` Eric S. Raymond 1 sibling, 1 reply; 185+ messages in thread From: Mike Castle @ 2002-01-02 23:44 UTC (permalink / raw) To: Linux Kernel List On Thu, Jan 03, 2002 at 12:23:45AM +0100, Lionel Bouton wrote: > Your whole point here is not to avoid several su instead of 1? Seems like the point is being able to do ``make autoconfig'' as a normal user, then su and make install modules_install. mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:44 ` Mike Castle @ 2002-01-03 0:11 ` Lionel Bouton 0 siblings, 0 replies; 185+ messages in thread From: Lionel Bouton @ 2002-01-03 0:11 UTC (permalink / raw) To: Linux Kernel List Mike Castle wrote: > On Thu, Jan 03, 2002 at 12:23:45AM +0100, Lionel Bouton wrote: > >>Your whole point here is not to avoid several su instead of 1? >> > > Seems like the point is being able to do ``make autoconfig'' as a normal > user, then su and make install modules_install. > Didn't thought this point enough. One identified stupid post on my side. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 23:23 ` Lionel Bouton 2002-01-02 23:44 ` Mike Castle @ 2002-01-03 2:20 ` Eric S. Raymond 1 sibling, 0 replies; 185+ messages in thread From: Eric S. Raymond @ 2002-01-03 2:20 UTC (permalink / raw) To: Lionel Bouton; +Cc: Dave Jones, Alan Cox, Linux Kernel List Lionel Bouton <Lionel.Bouton@free.fr>: > Eric I see your point now. But stop me if I don't get the idea behind > your autoconfigurator : > Guessing the hardware configuration is done in order to ease the whole > configuration process. After polishing the configuration - no need for > root priviledge - the user start the build process that doesn't need > root priviledge either. > But when the user gets the resulting kernel how does (s)he avoid suing > to root in order to *install* it and its modules ? > I'm not familiar with people configuring and compiling kernels for > pleasure. They usually want to boot it... > > Your whole point here is not to avoid several su instead of 1? That's actually *precisely* the point. The user should not have to go root for anything before the `make install' point. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The whole of the Bill [of Rights] is a declaration of the right of the people at large or considered as individuals... It establishes some rights of the individual as unalienable and which consequently, no majority has a right to deprive them of. -- Albert Gallatin, Oct 7 1789 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:48 ` Eric S. Raymond ` (3 preceding siblings ...) 2002-01-02 23:23 ` Lionel Bouton @ 2002-01-05 7:05 ` H. Peter Anvin 4 siblings, 0 replies; 185+ messages in thread From: H. Peter Anvin @ 2002-01-05 7:05 UTC (permalink / raw) To: linux-kernel Followup to: <20020102174824.A21408@thyrsus.com> By author: "Eric S. Raymond" <esr@thyrsus.com> In newsgroup: linux.dev.kernel > > But a setuid program *will not solve my problem*. > > The person running the autoconfigurator is not and should not be doing so > as root. Requiring the person to stop and sun sudo just so the > autoconfigurator can proceed is exactly the sort of pointless > obstacle we should *not* be putting in front of users! > Could you please look up what a setuid program *IS*? [Hint: a normal user can run them, and they get temporarily elevated privilege for the duration of that process only.] -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 22:08 ` Eric S. Raymond 2002-01-02 22:39 ` Alan Cox 2002-01-02 22:46 ` Lionel Bouton @ 2002-01-05 6:56 ` H. Peter Anvin 2 siblings, 0 replies; 185+ messages in thread From: H. Peter Anvin @ 2002-01-05 6:56 UTC (permalink / raw) To: linux-kernel Followup to: <20020102170833.A17655@thyrsus.com> By author: "Eric S. Raymond" <esr@thyrsus.com> In newsgroup: linux.dev.kernel > > But this is not a bad reason. Allowing people to avoid running suid > programs is a *good* reason. > In this case that is a nonsense reason, since what you're proposing doing is to change a userspace setuid program (which, on Unix, is functionally a privilege level between the kernel and normal userspace code) into kernel code. Not a win. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:47 ` Eric S. Raymond 2002-01-02 22:12 ` Dave Jones @ 2002-01-03 13:00 ` Horst von Brand 1 sibling, 0 replies; 185+ messages in thread From: Horst von Brand @ 2002-01-03 13:00 UTC (permalink / raw) To: Eric S. Raymond, Linux Kernel List "Eric S. Raymond" <esr@thyrsus.com> said: [...] > But only for people and programs with root privileges. It all turns > then, on whether we want to insist that all software doing hardware > probing must have root privileges to function. So bind it to a capability. > I submit that the answer is "no" -- the right direction, for security > and other reasons, is to make *fewer* capabilities dependent on root > privileges rather than more, and to reject design approaches that > imply creating more suid programs to give ordinary users capabilities > that involve only *reading* config information. Then create /etc/dmi or /var/log/dmi on boot from an initscript. /proc is a nice idea for _process_ information, the other junk in there should go away IMVHO. Hard to do as it is now customary. Adding more junk is (a) kernel bloat, (b) hard to clean up later. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:48 ` Dave Jones 2002-01-02 21:47 ` Eric S. Raymond @ 2002-01-02 21:59 ` Mike Castle 1 sibling, 0 replies; 185+ messages in thread From: Mike Castle @ 2002-01-02 21:59 UTC (permalink / raw) To: Linux Kernel List On Wed, Jan 02, 2002 at 10:48:28PM +0100, Dave Jones wrote: > Given that 'dmidecode' works fine in those circumstances, that's still > not a convincing argument imo. Except that is still has to run as root. Granted, this stuff is static, so running it once at boot to create a table that could be used by scripts could be useful. mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:30 ` Eric S. Raymond 2002-01-02 21:48 ` Dave Jones @ 2002-01-02 22:08 ` Alan Cox 1 sibling, 0 replies; 185+ messages in thread From: Alan Cox @ 2002-01-02 22:08 UTC (permalink / raw) To: esr; +Cc: Dave Jones, Alan Cox, Linux Kernel List > Consider the lives of people administering large server farms or clusters. > Their hardware is not necessarily homogenous, and the ability to query the DMI > tables on the fly could be useful both for administration and automatic > process migration. I considered it. If you take the base DMI table scanner you can trivially write a setuid app that simply outputs the DMI table block to fd 1. You can validate that app is secure, takes no arguments etc. On that basis it doesnt need the kernel involved ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:23 ` Bill Nottingham 2002-01-02 21:13 ` Eric S. Raymond @ 2002-01-02 21:22 ` Dave Jones 1 sibling, 0 replies; 185+ messages in thread From: Dave Jones @ 2002-01-02 21:22 UTC (permalink / raw) To: Bill Nottingham; +Cc: Alan Cox, esr, Linux Kernel List On Wed, 2 Jan 2002, Bill Nottingham wrote: > > And newer ones. I've seen 'Full length ISA slot' reported on a laptop > > for eg. > I have an ia64 here that, according to dmidecode, has a > 32bit NUBUS slot in it. AFAIK, that's not the case. ;) *grin*, for some things, DMI is reliable, others its down to whether individual bios vendors decide to add the relevant strings. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 20:15 ISA slot detection on PCI systems? Eric S. Raymond ` (2 preceding siblings ...) 2002-01-02 20:59 ` Alan Cox @ 2002-01-02 21:28 ` Christian Koenig 2002-01-02 22:04 ` Timothy Covell 3 siblings, 1 reply; 185+ messages in thread From: Christian Koenig @ 2002-01-02 21:28 UTC (permalink / raw) To: esr, Linux Kernel List Hi, On Wednesday 02 January 2002 21:15, Eric S. Raymond wrote: > Is there any way to safely probe a PCI motherboard to determine whether > or not it has ISA cards present, or ISA card slots? > > Note: the question is *not* about a probe for whether the board has an ISA > bridge, but a probe for the presence of actual ISA cards (or slots). > > (Yes, I'm working on a smart autoconfigurator. It's a development of > Giacomo Catenazzi's code, but able to use the CML2 deduction engine.) Nope, AFAIK even if the motherboard dosn't have ISA-Slots, the ISA-like chipset (DMA/old IRQ/Timer) is still present because off compatiblity reasons. But if you only want to know if a specified IO-range is on an ISA-card you could try to turn off the PCI-ISA brige, done this with Intel chipset before (they call this power saveing mode). MfG, Christian König. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: ISA slot detection on PCI systems? 2002-01-02 21:28 ` Christian Koenig @ 2002-01-02 22:04 ` Timothy Covell 0 siblings, 0 replies; 185+ messages in thread From: Timothy Covell @ 2002-01-02 22:04 UTC (permalink / raw) To: Christian Koenig, linux-kernel@vger.kernel.org On Wednesday 02 January 2002 15:28, Christian Koenig wrote: > Hi, > > On Wednesday 02 January 2002 21:15, Eric S. Raymond wrote: > > Is there any way to safely probe a PCI motherboard to determine whether > > or not it has ISA cards present, or ISA card slots? > > > > Note: the question is *not* about a probe for whether the board has an > > ISA bridge, but a probe for the presence of actual ISA cards (or slots). > > > > (Yes, I'm working on a smart autoconfigurator. It's a development of > > Giacomo Catenazzi's code, but able to use the CML2 deduction engine.) > > Nope, AFAIK even if the motherboard dosn't have ISA-Slots, the ISA-like > chipset (DMA/old IRQ/Timer) is still present because off compatiblity > reasons. Here's a good quotation from the lm_sensors man page: 2.3 I don't have an ISA bus! We promise, you do, even if you don't have any old ISA slots. The "ISA Bus" exists in your computer even if you don't have ISA slots; it is simply a memory-mapped area, 64KB in size (0x0000 - 0xFFFF) where many "legacy" functions, such as keyboard and interrupt controllers, are found. It isn't necessarily a separate physical bus. See the file /proc/ioports for a list of devices living on the "ISA Bus" in your system. If you don't like the term "ISA Bus" think "I/O Space". > > But if you only want to know if a specified IO-range is on an ISA-card you > could try to turn off the PCI-ISA brige, done this with Intel chipset > before (they call this power saveing mode). > > MfG, Christian König. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- timothy.covell@ashavan.org. ^ permalink raw reply [flat|nested] 185+ messages in thread
end of thread, other threads:[~2002-01-08 20:55 UTC | newest] Thread overview: 185+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-01-02 20:15 ISA slot detection on PCI systems? Eric S. Raymond 2002-01-02 20:45 ` Jeff Garzik 2002-01-02 20:46 ` Brian Gerst 2002-01-02 20:59 ` Alan Cox 2002-01-02 20:46 ` Eric S. Raymond 2002-01-02 21:13 ` Dave Jones 2002-01-02 21:19 ` Alan Cox 2002-01-02 21:04 ` Eric S. Raymond 2002-01-02 22:34 ` Alan Cox 2002-01-03 9:26 ` Vojtech Pavlik 2002-01-03 8:44 ` Eric W. Biederman 2002-01-03 12:46 ` Horst von Brand 2002-01-04 15:04 ` Kai Henningsen 2002-01-02 21:00 ` Dave Jones 2002-01-02 21:23 ` Bill Nottingham 2002-01-02 21:13 ` Eric S. Raymond 2002-01-02 21:31 ` Dave Jones 2002-01-02 21:30 ` Eric S. Raymond 2002-01-02 21:48 ` Dave Jones 2002-01-02 21:47 ` Eric S. Raymond 2002-01-02 22:12 ` Dave Jones 2002-01-02 22:08 ` Eric S. Raymond 2002-01-02 22:39 ` Alan Cox 2002-01-02 22:24 ` Eric S. Raymond 2002-01-02 22:50 ` Alan Cox 2002-01-02 22:34 ` Eric S. Raymond 2002-01-02 23:09 ` Alan Cox 2002-01-02 23:09 ` Eric S. Raymond 2002-01-02 23:52 ` Alan Cox 2002-01-02 23:56 ` Mike Castle 2002-01-03 0:00 ` Dave Jones 2002-01-03 0:37 ` Mike Castle 2002-01-03 0:58 ` Dave Jones 2002-01-03 13:35 ` Horst von Brand 2002-01-03 13:46 ` Dave Jones 2002-01-03 16:42 ` Horst von Brand 2002-01-03 18:06 ` Alex 2002-01-03 18:16 ` Horst von Brand 2002-01-03 18:22 ` Patrick Mochel 2002-01-03 22:26 ` Alan Cox 2002-01-03 22:20 ` Patrick Mochel 2002-01-03 22:31 ` Alan Cox 2002-01-03 18:41 ` Gábor Lénárt 2002-01-03 22:24 ` Alan Cox 2002-01-07 21:56 ` Mark H. Wood 2002-01-03 13:10 ` Horst von Brand 2002-01-02 22:53 ` Mike Castle 2002-01-02 23:16 ` Alan Cox 2002-01-02 23:31 ` Dave Jones 2002-01-02 23:04 ` Lionel Bouton 2002-01-03 3:49 ` Cameron Simpson 2002-01-03 4:03 ` Dave Jones 2002-01-03 6:46 ` Mike Castle 2002-01-03 12:35 ` Alan Cox 2002-01-03 12:39 ` Vojtech Pavlik 2002-01-05 7:03 ` H. Peter Anvin 2002-01-05 17:16 ` Albert D. Cahalan 2002-01-05 17:34 ` Dave Jones 2002-01-05 20:29 ` H. Peter Anvin 2002-01-06 1:19 ` Dave Jones 2002-01-06 12:19 ` Mr. James W. Laferriere 2002-01-06 13:16 ` Dave Jones 2002-01-06 15:26 ` Mr. James W. Laferriere 2002-01-06 18:20 ` Dave Jones 2002-01-07 13:35 ` Mr. James W. Laferriere 2002-01-06 21:03 ` Vojtech Pavlik 2002-01-06 22:16 ` Alan Cox 2002-01-07 7:42 ` Vojtech Pavlik 2002-01-03 16:00 ` Cryto verification of Kernel against Trojan code?? Timothy Covell 2002-01-03 21:58 ` ISA slot detection on PCI systems? Cameron Simpson 2002-01-03 21:15 ` Lionel Bouton 2002-01-03 21:26 ` Dave Jones 2002-01-05 6:58 ` H. Peter Anvin 2002-01-02 22:46 ` Lionel Bouton 2002-01-02 22:51 ` Dave Jones 2002-01-02 22:48 ` Eric S. Raymond 2002-01-02 23:10 ` Dave Jones 2002-01-03 2:10 ` Eric S. Raymond 2002-01-03 2:44 ` Dave Jones 2002-01-03 3:03 ` Eric S. Raymond 2002-01-03 3:26 ` Dave Jones 2002-01-03 3:18 ` Eric S. Raymond 2002-01-03 3:36 ` Brian Gerst 2002-01-03 3:35 ` Eric S. Raymond 2002-01-03 4:15 ` Brian Gerst 2002-01-03 4:15 ` Eric S. Raymond 2002-01-03 4:27 ` Brian Gerst 2002-01-03 4:30 ` Eric S. Raymond 2002-01-03 3:39 ` Dave Jones 2002-01-03 3:34 ` Brian Gerst 2002-01-03 14:37 ` Horst von Brand 2002-01-04 7:09 ` [OT] " Paul Duncan 2002-01-03 11:25 ` Henrik Hovi 2002-01-05 7:09 ` H. Peter Anvin 2002-01-03 14:31 ` Horst von Brand 2002-01-03 15:00 ` Jesse Pollard 2002-01-03 15:15 ` Richard B. Johnson 2002-01-04 15:30 ` Kai Henningsen 2002-01-03 5:30 ` Andrew Morton 2002-01-03 5:42 ` Jeff Garzik 2002-01-03 5:55 ` Daniel Phillips 2002-01-03 5:46 ` Eric S. Raymond 2002-01-03 9:14 ` David Woodhouse 2002-01-03 9:09 ` Eric S. Raymond 2002-01-03 12:14 ` Alan Cox 2002-01-03 12:34 ` Vojtech Pavlik 2002-01-04 18:28 ` Maciej W. Rozycki 2002-01-04 19:04 ` Vojtech Pavlik 2002-01-04 19:05 ` Eric S. Raymond 2002-01-04 19:21 ` Vojtech Pavlik 2002-01-04 19:41 ` Eric S. Raymond 2002-01-04 20:09 ` Dave Jones 2002-01-08 12:52 ` Rob Landley 2002-01-04 20:19 ` David Weinehall 2002-01-04 20:30 ` Maciej W. Rozycki 2002-01-04 20:36 ` Eric S. Raymond 2002-01-05 7:12 ` H. Peter Anvin 2002-01-04 20:20 ` Vojtech Pavlik 2002-01-04 20:44 ` Eric S. Raymond 2002-01-04 19:45 ` Dave Jones 2002-01-04 19:50 ` Maciej W. Rozycki 2002-01-04 19:54 ` Dave Jones 2002-01-04 20:24 ` Maciej W. Rozycki 2002-01-04 20:31 ` Dave Jones 2002-01-04 20:33 ` Eric S. Raymond 2002-01-04 20:56 ` Vojtech Pavlik 2002-01-04 20:57 ` Dave Jones 2002-01-04 20:49 ` Eric S. Raymond 2002-01-04 21:08 ` Dave Jones 2002-01-04 20:59 ` Eric S. Raymond 2002-01-04 21:18 ` Dave Jones 2002-01-04 21:23 ` Patrick Mochel 2002-01-05 0:13 ` Alan Cox 2002-01-04 21:17 ` David Woodhouse 2002-01-04 21:04 ` Charles Cazabon 2002-01-05 17:28 ` Horst von Brand 2002-01-04 19:36 ` Maciej W. Rozycki 2002-01-04 19:45 ` Vojtech Pavlik 2002-01-04 20:08 ` Maciej W. Rozycki 2002-01-03 16:52 ` Rik van Riel 2002-01-03 17:01 ` Dave Jones 2002-01-03 17:27 ` Eric S. Raymond 2002-01-03 9:24 ` David Woodhouse 2002-01-03 14:12 ` Horst von Brand 2002-01-03 3:07 ` Greg Hennessy 2002-01-03 9:08 ` David Woodhouse 2002-01-03 9:03 ` Eric S. Raymond 2002-01-03 12:20 ` Alan Cox 2002-01-03 12:07 ` BALBIR SINGH 2002-01-03 12:40 ` Alan Cox 2002-01-03 21:44 ` Lionel Bouton 2002-01-03 22:17 ` David Weinehall 2002-01-04 18:41 ` Maciej W. Rozycki 2002-01-03 22:36 ` Alan Cox 2002-01-04 12:10 ` Alex 2002-01-04 12:20 ` Dave Jones 2002-01-04 12:22 ` Alex 2002-01-04 12:30 ` Dave Jones 2002-01-04 12:47 ` Alex 2002-01-03 12:56 ` Urban Widmark 2002-01-03 9:19 ` David Woodhouse 2002-01-03 9:12 ` Eric S. Raymond 2002-01-03 9:31 ` David Woodhouse 2002-01-03 10:34 ` Kai Henningsen 2002-01-03 14:42 ` Dave Jones 2002-01-04 15:39 ` Kai Henningsen 2002-01-02 23:15 ` Alan Cox 2002-01-02 23:07 ` Eric S. Raymond 2002-01-02 23:33 ` Lionel Bouton 2002-01-02 23:37 ` Dave Jones 2002-01-03 2:19 ` Eric S. Raymond 2002-01-03 2:17 ` Eric S. Raymond 2002-01-02 23:19 ` Mike Castle 2002-01-02 23:23 ` Lionel Bouton 2002-01-02 23:44 ` Mike Castle 2002-01-03 0:11 ` Lionel Bouton 2002-01-03 2:20 ` Eric S. Raymond 2002-01-05 7:05 ` H. Peter Anvin 2002-01-05 6:56 ` H. Peter Anvin 2002-01-03 13:00 ` Horst von Brand 2002-01-02 21:59 ` Mike Castle 2002-01-02 22:08 ` Alan Cox 2002-01-02 21:22 ` Dave Jones 2002-01-02 21:28 ` Christian Koenig 2002-01-02 22:04 ` Timothy Covell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox