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
"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
> 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.
"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
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
Alan Cox <[email protected]>:
> 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!
> 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
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
Dave Jones ([email protected]) 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
Alan Cox <[email protected]>:
> > 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.
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
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.
Bill Nottingham <[email protected]>:
> Dave Jones ([email protected]) 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
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
Dave Jones <[email protected]>:
> 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
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
> 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
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 [email protected] http://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
Dave Jones <[email protected]>:
> > 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.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
[email protected].
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
Dave Jones <[email protected]>:
> 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
> 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.
> 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
Alan Cox <[email protected]>:
> 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
> 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
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.
Alan Cox <[email protected]>:
> > 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.
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
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 [email protected] http://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
> 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.
Dave Jones <[email protected]>:
> > 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.
> 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)
> (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.
Eric S. Raymond wrote:
> Alan Cox <[email protected]>:
>
>>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.
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
Alan Cox <[email protected]>:
> > (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.
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 [email protected] http://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
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.
Alan Cox <[email protected]>:
> 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)
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
Eric S. Raymond wrote:
> Alan Cox <[email protected]>:
>
>>>(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.
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
> > 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"
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 [email protected] http://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
On Wed, Jan 02, 2002 at 06:09:26PM -0500, Eric S. Raymond wrote:
> Alan Cox <[email protected]>:
> > 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 [email protected] http://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
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
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.
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 [email protected] http://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
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
Dave Jones <[email protected]>:
> 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.
Lionel Bouton <[email protected]>:
> 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
Dave Jones <[email protected]>:
> 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
Lionel Bouton <[email protected]>:
> 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
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
In article <[email protected]>,
Dave Jones <[email protected]> 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. :)
Dave Jones <[email protected]>:
> 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'
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
Dave Jones <[email protected]>:
> 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
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
"Eric S. Raymond" wrote:
>
> Dave Jones <[email protected]>:
> > 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
"Eric S. Raymond" wrote:
>
> Dave Jones <[email protected]>:
> > 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
Brian Gerst <[email protected]>:
> > 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
On Thu, Jan 03, 2002 at 12:04:57AM +0100, Lionel Bouton <[email protected]> wrote:
| Eric S. Raymond wrote:
| > Alan Cox <[email protected]>:
| >>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 [email protected] 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
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
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
Brian Gerst <[email protected]>:
> > 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
"Eric S. Raymond" wrote:
>
> Brian Gerst <[email protected]>:
> > > 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
Brian Gerst <[email protected]>:
> > 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
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.
-
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
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
Andrew Morton <[email protected]>:
> 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
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 [email protected] http://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
"Eric S. Raymond" <[email protected]> writes:
> Alan Cox <[email protected]>:
> > 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
[email protected] 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
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
David Woodhouse <[email protected]>:
> > 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
[email protected] 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
David Woodhouse <[email protected]>:
> 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"
[email protected] 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
David Woodhouse <[email protected]>:
> 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
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
[email protected] 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
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 <[email protected]>:
> > 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
> 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
> 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
|> 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
> 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
> 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
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
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
"Eric S. Raymond" <[email protected]> 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
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
"Eric S. Raymond" <[email protected]> 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
"Eric S. Raymond" <[email protected]> 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
Dave Jones <[email protected]> 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
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
"Eric S. Raymond" <[email protected]> said:
> Dave Jones <[email protected]>:
[...]
> > 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
[email protected] (Dave Jones) wrote on 03.01.02 in <[email protected]>:
> 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
"Eric S. Raymond" <[email protected]> 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
Brian Gerst <[email protected]> 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
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
--------- Received message begins Here ---------
>
> "Eric S. Raymond" <[email protected]> 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: [email protected]
Any opinions expressed are solely my own.
On Thu, 3 Jan 2002, Horst von Brand wrote:
> "Eric S. Raymond" <[email protected]> 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.
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.)
--
[email protected].
Dave Jones <[email protected]> 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
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/
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
Dave Jones <[email protected]>:
> > > 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
> 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
Alex <[email protected]> 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
> 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
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
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.
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
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.
On Thu, Jan 03, 2002 at 12:35:36PM +0000, Alan Cox <[email protected]> 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 [email protected] 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
> 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
> 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
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 <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
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
> > 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
> 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)
* Brian Gerst ([email protected]) 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 <[email protected]> pabs on #e (OPN IRC)
http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562
Hello.
I have some comments about the thread (to make some
order).
Aunt Tillie:
Linus shared Linux as a 'game' for other hackers (10 years ago).
Now some 'Aunt Tillie' use Linux.
Thus maybe in few years all 'Aunt Tillie' will compile the
own kernel.
The difference between Linus and the other elder brother
(and also the elder bad boy) is the availability of sources.
IMHO we should enlarge this difference, thus the sources
should no be a add-on for geek, but for all.
Let all *use* the source!
DMI.
I really don't like dmi. On my development machine (a
laptop), I have the BAD video card (which force me to
taint the kernel, someone in this thread tell us
the it is a 'not plus ultra' but...).
The DMI tell me that the card is a good ATI. (
The bios is uptodate)
[machine: Dell i8k, not a noname]
This with other bad DMI report tell me that dmi is
not yet reliable [2001/2002]
ISA and PCI
Eric: There is not need to make to much assertions.
I told you about the HEURISTIC mode.
If we found a moderm machine, with PCI bus, let forget
about ISA.
If there is a ISA card, and it is important, the current
kernel have already detected it (and maybe it is using it),
so the detection routines should already have indluced it.
The main think to remember is that kernel make already the
important detections, and we can use the result to make
a machine bootable. [important = necessary to boot and to
make the machine usable]
The big driver database is to set up the better drivers,
the newer devices, the less common driver (the
distributions did not compile all availables modules), ...
[and it is easyer to make that checking the printk string]
[ This will work for the normal user. If someone
will use the autodetection for the 'boot-cdrooms',
(to find the better kernel), the things are
complexer, but the 'boot cdrooms' people are good
programmers, so they will find a extra solution]
What I will do:
I check the .config of main distributions [could
someone send to me the latest official .config],
and I'll find what are the common/default ISA cards.
Than I make sure that the autodetection *will*
detect such cards via dmesg, /proc,...
So this thread is solved.
[the purpose, still we had not the tools
that enumerate all ISA card. But this tool
is impossible to build]
giacomo
> I check the .config of main distributions [could
> someone send to me the latest official .config],
> and I'll find what are the common/default ISA cards.
We enable almost all - but as modules. Non ISAPnP/PCI/otherwise detectable
devices require user intervention via the GUI config tools or by editing
modules.conf
Except for the sound configuration the number of people this hits is very
low indeed.
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
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
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
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
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
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: [email protected], PGP key available +
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: [email protected], PGP key available +
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
Vojtech Pavlik <[email protected]>:
> 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
On Fri, Jan 04, 2002 at 02:05:38PM -0500, Eric S. Raymond wrote:
> Vojtech Pavlik <[email protected]>:
> > 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
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: [email protected], PGP key available +
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
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
[email protected] (Horst von Brand) wrote on 03.01.02 in <[email protected]>:
> "Eric S. Raymond" <[email protected]> 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
[email protected] (Dave Jones) wrote on 03.01.02 in <[email protected]>:
> 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
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: [email protected], PGP key available +
[email protected] (Richard B. Johnson) wrote on 03.01.02 in <[email protected]>:
> 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
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
Vojtech Pavlik <[email protected]>:
> 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
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: [email protected], PGP key available +
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
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 <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Fri, Jan 04, 2002 at 02:41:46PM -0500, Eric S. Raymond wrote:
> Vojtech Pavlik <[email protected]>:
> > 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
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: [email protected], PGP key available +
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
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: [email protected], PGP key available +
Dave Jones <[email protected]>:
> 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
Maciej W. Rozycki <[email protected]>:
> > 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
On Fri, Jan 04, 2002 at 03:33:05PM -0500, Eric S. Raymond wrote:
> Dave Jones <[email protected]>:
> > 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
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
Vojtech Pavlik <[email protected]>:
> 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
Eric S. Raymond <[email protected]> wrote:
> Dave Jones <[email protected]>:
> > 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 <[email protected]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------
Dave Jones <[email protected]>:
> 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
On Fri, 4 Jan 2002, Eric S. Raymond wrote:
> Dave Jones <[email protected]>:
> > 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
Dave Jones <[email protected]>:
> > 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.
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
[email protected] 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
On Fri, 4 Jan 2002, Eric S. Raymond wrote:
> Dave Jones <[email protected]>:
> > > 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
> > ACPI
>
> OK. So can I ask ACPI if the board has ISA slots? Does it answer
> reliably?
On current evidence - no.
Followup to: <[email protected]>
By author: "Eric S. Raymond" <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: "Eric S. Raymond" <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: Vojtech Pavlik <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: "Eric S. Raymond" <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: Henrik Hovi <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: "Eric S. Raymond" <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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.
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
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
"Eric S. Raymond" <[email protected]> said:
> Dave Jones <[email protected]>:
> > 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 [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
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
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 |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
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
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 |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
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
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
> 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
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
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 |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
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 [email protected]
Our lives are forever changed. But *that* is exactly as it always was.
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