ISA slot detection on PCI systems?
Eric S. Raymond
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Jones
> 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
> 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.
Brian Gerst
>
> Is there any way to safely probe a PCI motherboard to determine whether
> or not it has ISA cards present, or ISA card slots?
>
> 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
Jeff Garzik
>
> 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
Dave Jones
> 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
> > 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.
Alan Cox
> 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
Dave Jones
> 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
-
Eric S. Raymond
> 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!
Bill Nottingham
> > 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
>
> 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
Christian Koenig
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.
Eric S. Raymond
> > 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?
>
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.
Eric S. Raymond
> Dave Jones (da...@suse.de) said:
> > > You can make an educated guess. However it is at best an educated guess.
> > > The DMI tables will tell you what PCI and ISA slots are present (but
> > > tend to be unreliable on older boxes).
> >
> > And newer ones. I've seen 'Full length ISA slot' reported on a laptop
> > for eg.
>
> I have an ia64 here that, according to dmidecode, has a
> 32bit NUBUS slot in it. AFAIK, that's not the case. ;)
I just downloaded and tested Arjan deVen's dmidecode.c program.
That will do what I want, but it has the irritating problem that
it requires root privileges for access to /dev/kmem.
Is the DMI data available in /proc files anywhere?
If not, should it be?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Taking my gun away because I might shoot someone is like cutting my tongue
out because I might yell `Fire!' in a crowded theater."
-- Peter Venetoklis
Dave Jones
> 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
-
Alan Cox
> 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
Eric S. Raymond
> 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
Mike Castle
> 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 dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Eric S. Raymond
> > 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.
>
> 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.
Alan Cox
> > 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.
Alan Cox
> 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
> 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
Lionel Bouton
> [...]
>
> 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.
Dave Jones
> > 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
-
Alan Cox
> 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.
Eric S. Raymond
> 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
Dave Jones
> > > 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
-
Timothy Covell
> 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 majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Eric S. Raymond
> 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
Alan Cox
>
> dmidecode > /var/run/dmi
Absolutely nothing, and that also handily means it isnt setuid 8)
Dave Jones
> > > 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
-
Mike Castle
> 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 dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Alan Cox
> 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
> > 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*.
>
>
> 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.
Lionel Bouton
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
>
>>So you want the lowest possible priviledge level. Because if so thats
>>setuid app not kernel space. Arguing about the same code in either kernel
>>space verus setuid app space is garbage.
>>
>
> But you're thinking like a developer, not a user. The right question
> is which approach requires the lowest level of *user* privilege to get
> the job done. Comparing world-readable /proc files versus a setuid app,
> the answer is obvious.
Reading proc files requires running kernel space code, do we have kernel
space code running with *user* priviledge now?
> This sort of thing is exactly what /proc is *for*.
>
Hum, "/proc" is only good for _flamewars_ on lklm ;-)
LB.
Eric S. Raymond
> > 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.
Eric S. Raymond
> > (Telling me to rely on dmidecode already being installed SUID is not
> > a good answer either. No prizes for figuring out why.)
>
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.
Eric S. Raymond
> 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)
Mike Castle
> 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 dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Lionel Bouton
> [...]
> 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.
Dave Jones
> > 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
-
Dave Jones
> > 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.
Alan Cox
> > 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"
Lionel Bouton
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
>
>>>(Telling me to rely on dmidecode already being installed SUID is not
>>>a good answer either. No prizes for figuring out why.)
>>>
>>Well you can't rely on the kernel having the modification either.
>>
>
> If /proc/dmi were to go in soon, at least I *could* rely on it in 2.6.
>
If in rc.sysinit a call to "dmidecode > /var/run/dmi" were to go in the
user space 2.6 kernel build dependancies in Documentation/Changes,
you'll be on the same level.
Lionel Bouton
> 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.
Dave Jones
> 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
> 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 dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Mike Castle
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
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
Dave Jones
> 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
-
Mike Castle
> 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 dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Eric S. Raymond
> 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
Eric S. Raymond
> 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...
>
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
Eric S. Raymond
> On Thu, 3 Jan 2002, Lionel Bouton wrote:
>
> > user space 2.6 kernel build dependancies in Documentation/Changes,
> > you'll be on the same level.
>
> 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
Eric S. Raymond
> 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.
Dave Jones
> > 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
-
Greg Hennessy
Dave Jones <da...@suse.de> wrote:
> And if you don't know what hardware you've got in the box your
> configuring a kernel for, its questionable that you should be
> doing so in the first place.
I admister machines that are old enough I've forgotten what hardware
they have in them. :)
Eric S. Raymond
> 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
Dave Jones
> 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
> 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.
Eric S. Raymond
> 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'
Brian Gerst
>
> Dave Jones <da...@suse.de>:
> > Go down the DMI path, and get it right _sometimes_, or take a zero.
> > Getting it right sometimes is likely to do more harm than good.
>
> 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
Dave Jones
> > 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
> > Not in this case. If the DMI read fails, the worst-case result is the
> > user sees some ISA extra questions.
>
> 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
Brian Gerst
> > '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
Cameron Simpson
| Eric S. Raymond wrote:
| > Alan Cox <al...@lxorguk.ukuu.org.uk>:
| >>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 c...@zip.com.au http://www.zip.com.au/~cs/
Although it does not mindfully keep guard, in the small mountain fields the
scarecrow does not stand in vain. - trans. Bukkoku Kokushi
Brian Gerst
>
> Brian Gerst <bge...@didntduck.org>:
> > > Nobody has told me this is a real failure case yet. To cause a problem,
> > > the situation would have to be that DMI read fails to detect a card in
> > > use in an ISA slot. It's OK if it reports no slots when all slots are
> > > empty.
> >
> > 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
Eric S. Raymond
> > 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
Brian Gerst
> > > 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.
>
> the situation would have to be that DMI read fails to detect a card in
> use in an ISA slot. It's OK if it reports no slots when all slots are
> empty.
Well, I just popped in an old 3com 509TP network card (non-PnP) into my
main box and dmidecode still failed to show the single ISA slot, only 4
PCI and 1 AGP.
--
Brian Gerst
Eric S. Raymond
> > 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.
>
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
Andrew Morton
>
> 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.
-
Jeff Garzik
>
> 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
Eric S. Raymond
> 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
Mike Castle
> - 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 dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Eric W. Biederman
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
> > You can make an educated guess. However it is at best an educated guess.
> > The DMI tables will tell you what PCI and ISA slots are present (but
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > tend to be unreliable on older boxes). You can also look for an ISA bridge
> > in lspci as a second source of information.
>
> That sounds like it might be what I'm after. My goal is to be able to probe
> the machine and set ISA_CARDS based on the probe. What's a DMI table and
> how can I query it for the presence of ISA slots?
>
> What I want to do with this is make ISA-card questions invisible on modern
> PCI-only motherboards.
Auto configuration only works for some variety of Plug-and-Play hardware.
By that I mean that between a combination of the firmware and the hardware
you can detect what is there. Plug-and-Play does not work reliably on
ISA. Since PCI has been Plug-and-Play from the start it works well.
I would suggest you assume that for any hardware that isn't present
you assume it isn't there.
For those things where auto detection is not reliable have a menu that
let's you manually select the which pieces you actually want to worry
about sounds reasonable.
Say:
Unprobeable hardware support
ISA cards
i2c devices
lpc devices
etc
etc.
With the kernel moving to support more and more hardware and things
like lm-sensors showing up. Even the absence of slots does not mean
that there aren't pieces that software can not get adequate
information to setup correctly.
As for DMI and it's ilk. The only sane thing I can see to do is have
something that will report the motherboard id. (DMI does seem to do
that fairly reiliably, as do MP tables). And then you build a
database based on motherboard id upon the capabilities of the various
motherboards.
Looking up the datasheets from the various manufacturers should not be
to hard of a job.. Plus it is a technique that can work on things
other than stock PC's.
Eric
David Woodhouse
e...@thyrsus.com said:
> Think useability. On Macintoshes, you configure a kernel by moving
> the equivalents of modules in and out of a system folder. Users tune
> their kernels by moving files around -- no muttering of elaborate
> incantations required. *That's* the direction we should be moving in;
> there is no good technical reason for the process to be anywhere near
> as arcane as it is now.
We have it better than that already. The distro vendor provides all the
modules and they're automatically loaded on demand - you don't even need to
move them into the system folder.
--
dwmw2
David Woodhouse
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.
David Woodhouse
e...@thyrsus.com said:
> So you're saying the users should be completely lost any time they
> want to use an upated kernel?
Not at all - that's what up2date is for. If I want something newer than the
latest certified erratum release from some vendor with a clue, then I
probably ought to know what I'm doing.
Making it _easier_ for Aunt Tillie to install something like 2.4.10 is not
necessarily doing her a favour.
Vojtech Pavlik
> > > 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
David Woodhouse
e...@thyrsus.com said:
> You have my intentions backwards. What I'd like to be able to do is
> suppress ISA_SLOTS when there are detectably *no* ISA cards.
> Unfortunately I have had it demonstrated that the DMI tables can give
> false negatives (false positives would not have been a showstopper).
I suggest you just suppress it anyway unless you're in normal
configuration mode. As you say - you don't need to care too much about
ancient hardware, and if they have ISA cards they're going to _need_ to
know what's in the box anyway.
--
dwmw2
David Woodhouse
e...@thyrsus.com said:
> > Making it _easier_ for Aunt Tillie to install something like 2.4.10 is
> > not necessarily doing her a favour.
> But making it unnecessarily harder is *certainly* not a favor.
Making it _gratuitously_ harder isn't called for, true - but it's definitely
not a case we need to _optimise_ for.
I'm surprised you feel the need to do it, but I'll not try and stop you - as
long as in doing so you don't make it more difficult for the people who _do_
actually do this all day every day.
Eric S. Raymond
> > 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
Eric S. Raymond
> 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"
Eric S. Raymond
> 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
Henrik Hovi
can't most of the time.
On Wed, 2 Jan 2002, Eric S. Raymond wrote:
> Dave Jones <da...@suse.de>:
> > See other posting with examples of dramatic failures of
> > 'slots in box, but dmi says none' and 'no slots, dmi says some'.
> > still think this is usable ? You're nuts.
>
> One of my background assumptions is that the older a machine is, the
> more likely it is that the person doing the config will have a clue about
> what they're doing. These days hardware is so cheap that only geeks try
> to cram Linux onto old systems -- and even the geeks mostly do it just to
> prove they can.
>
> Thus I'm not very worried about DMI read failing on older hardware.
> My main objective is to make configuration painless on modern PCI-only
> hardware -- which is why I want to be able to tell when there are no
> ISA slots, so I can deep-six questions about ISA drivers.
These days hardware is cheap. BUT most of the people using their computer
as a typewriter and a means to easily do the important things with the
bank are NOT ready to upgrade to a new state-of-art Itanium 2GHz byte
crusher with a nice GeForce 5 accelerator and an integrated coffee cooker
(okay, they would like that one) even though they were cheaper than a
pair socks. The world doesn't work that way. They don't need such
monsters and that's it.
I thought Linux was also about coding software that would work with all
hardware including computers more than two years old. This DMI thingie
seems like it could pretty efficiently fuck up everything with such
puters. It would be fine for newer Athlons and P3s if one could trust
hardware vendors.
> > You're solving a non-problem.
> > Some examples of target audience you're aiming for in your previous
> > mail were I believe..
> >
> > o The geek next door who wants to tinker and learn about the kernel.
> > Said geek is going to learn a damn sight more currently than he will
> > with a dumbed down pointy clicky "build me a kernel" button.
>
> Your "they must show willingness to suffer pain, otherwise they're not worthy"
> attitude is really showing here.
The geek next door is already capable of compiling the kernel by reading a
bit of the fine manuals and I wouldn't worry a bit about him not becoming
the best kernel hacker in the world. He will get angry with the bugs and
the people supposed to fix them sooner or later. The geek next door is
what we've all been. Even though there was the easy way, we preferred the
hard (and stupid) way.
> I'm not proposing that the "dumbed-down" version be the only version, but that
> the kernel and the config tools make "build me a kernel at the push of a
> button *possible* for those who don't want to go any deeper.
>
> > o Aunt Tilley.
> > Vendors already ship an array of kernels which should make it
> > unnecessary for her to have to build a kernel.
>
> Yes. But *I* want Aunt Tilley to be able to download the latest kernel
> sources and build/install them herself, without ever feeling that the task
> is beyond her capabilities.
Aunt Tilley is the main issue here. An average Aunt Tilley would propably
have an oldish machine she can write amateur romantic novels and emails to
her nephews with. She'll be perfectly happy with it until it crashes. It
is also propable that, if she has Linux on her typewriter, one of her
nephews (let's call him Bob) is doing the administration. Although Aunt
Tilley is the sweetest person on Earth, Bob doesn't much like about
constantly cycling the 20 miles from home to Aunt Tilley's just to compile
a kernel. He will propably try his best to teach Aunt Tilley to install
the newest kernel-image rpm package form the net from time to time.
That should be the direction we're headed. "Forcing" people to use
pre-compiled kernels is what we are doing now (and that's what people in
Redmond are doing too). I wouldn't expect Aunt Tilley to be genuinely
interested in the process of compiling the kernel. She won't know much
about it but still, she should be able to do it. If she happened to have
one of those computers whose DMI sucks big time and we asked her wether
she wanted to get all her ISA devices auto-probed, she would answer yes.
When the kernel would panic, Aunt Tilley would be frightened and never
upgrade anything again or worse: switch back to Windows which she knows
"stable" and "secure".
> Part of the reason I want this is for the capability itself; partly I want
> it pour encourager les autres -- to demonstrate, by tackling one of the
> toughest cases, that much of the complexity and anti-useability of Linux
> is an artificial and unnecessary creation of the culture that created it,
> rather than a result of actual technical depth of the problem.
You cannot tackle this case without first searching an answer which is not
DMI. It seems like there was none. It is safer making the autoconfig guess
the ISA configuration so that it would work with any computer without
non-PNP ISA devices. One or two extra configuration options will hurt no
one.
> I believe we need to learn the discipline of useability and take it seriously.
> Because talk plus code is much more convincing than just talk, I'm trying
> to demonstrate this by coding. But I'll talk about it too :-).
>
> > If you still think world domination is going to appear by idiotproofing
> > the kernel build process, I think you're in for a surprise.
> > We have far bigger usability problems in userspace. The point is that
> > $newcomertolinux doesn't need to know what a kernel is, let alone
> > have to build one. They just see "Booting progress" "Log in" "Desktop".
A newcomer doesn't know what a kernel is but the security of his/her data
is the reason why we need to tell him/her. Pre-compiled kernels might come
with bugs already fixed (which makes them also wide known).
> Sure we have bigger idiotproofing problems. But this is the one that
> (a) my skillset is well matched to, and (b) no one else is worrying about.
There is another way to idiotproof software. We need good manuals, not
just the laughable man pages and the Documentation directory in the source
package. WTFM so that $ordinaryperson can RTFM. We should also learn
another thing from the commercial world: product placement. Even though
there are manuals I would classify as average, they are not where they're
supposed to be and people have to do some serious googling before they can
solve a minor problem not covered properly by the man page or linuxdoc.org.
> World domination will happen, if it happens, because lots of people
> are willing to obsess about useability issues at *all* levels of the
> system. Including this one.
Eric, you're a big dreamer and you have wonderful dreams, but please keep
yourself near to the ground. This is not too big a problem. My P133 has
two ISA devices and they both are ISAPNP. That computer just had it's
seventh birthday. If the automatised configuration makes guesses good
enough, the dear old byte crusher will be just fine.
And Dave, what's wrong with world domination anyway? ;)
Henrik
Alan Cox
> 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
Alan Cox
> 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
Alan Cox
> 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
Alan Cox
> 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
Vojtech Pavlik
> > 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
BALBIR SINGH
|> 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
Vojtech Pavlik
> > 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 ...
Horst von Brand
[...]
> 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
Horst von Brand
[...]
> 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.
Urban Widmark
> > 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
Horst von Brand
[...]
> 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
Horst von Brand
> 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...
Dave Jones
> 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
Horst von Brand
[...]
> 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
Horst von Brand
[...]
> > 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.