ISA hardware discovery -- the elegant solution

ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

I've been thinking about the hardware-discovery problem for ISA devices,
and there may be an elegant solution.  It will take a number of small changes
to the kernel sources, however.

The kernel's device drivers have, of course, to include probe
routines, and those hard-compiled in typically log the presence of
their hardware to /var/log/mesg when it loads.  By scanning that
file, we in effect get to use those probes.

My autoconfigurator's probe table now has a small number of tests than 
do regexp matches against the dmesg log.  As is, this solution does not
scale well, because each regexp has to be discovered by eyeball and then
maintained in the table by hand.

But suppose the format of boot-time driver messages were standardized in a
format that included their config symbol in a discoverable form?

I have hand-edited a copy of my current /var/log/dmesg to illustrate
how I think this could work.  

:MTRR: your CPUs had inconsistent fixed MTRR settings
:MTRR: probably your BIOS does not setup all CPUs
:PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
:PCI: Using configuration type 1
:PCI: Probing PCI hardware
BIOS disabled PCI ordering compliance, so we enabled it again.
:IO_APIC: AMD Errata #22 may be present. In the event of instability try
        : booting with the "noapic" option.
:NET: Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
:RTNETLINK: Initializing RT netlink socket
Starting kswapd
allocated 32 pages and 32 bhs reserved for the highmem bounces
:JBD: Journalled Block Device driver loaded
:UNIX_PTY: 2048 Unix98 ptys configured
block: 128 slots per queue, batch=32
:IDE: Uniform Multi-Platform E-IDE driver Revision: 6.31
:IDE: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
:SCSI: SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

  Vendor: IBM-PSG   Model: ST318451LW    !#  Rev: B833
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: IBM-PSG   Model: ST318451LW    !#  Rev: B833
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: HP        Model: C5683A            Rev: C005
  Type:   Sequential-Access                  ANSI SCSI revision: 02
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi0:A:1:0: Tagged Queuing enabled.  Depth 253
  Vendor: PIONEER   Model: DVD-ROM DVD-305   Rev: 1.00
  Type:   CD-ROM                             ANSI SCSI revision: 02
  Vendor: PLEXTOR   Model: CD-R   PX-W1210S  Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 35548320 512-byte hdwr sectors (18201 MB)
Partition check:
 sda: sda1 sda2 < sda5 >
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sdb: 35548320 512-byte hdwr sectors (18201 MB)
 sdb: sdb1 sdb2
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0
(scsi1:A:0): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
(scsi1:A:1): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
:USB_DEVFS: registered new driver usbdevfs
:USB: registered new driver hub
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 96k freed
Adding Swap: 1807272k swap-space (priority -1)
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,5), internal journal
:BLK_DEV_MD: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
kjournald starting.  Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,18), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
:BLK_DEV_ST: Version 20011103, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0

The convention I propose is that at least one line of a driver probe message
should begin with :, followed by the driver config symbol, followed by :.
I am not attached to that particular punctuation, it is simply an unambiguous
way of indicating "this is a config symbol".

With this change, generating a report on ISA hardware and other
facilities configured in at boot time would be trivial.  This would
make the autoconfigurator much more capable.  Best of all, the only
change required to accomplish this would be safe edits of print format
strings.

I would be willing to generate a patch to implement this change.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
	-- Lazarus Long 

Re: ISA hardware discovery -- the elegant solution

[Larry McVoy]

> :MTRR: your CPUs had inconsistent fixed MTRR settings
> :MTRR: probably your BIOS does not setup all CPUs
> :PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
> :PCI: Using configuration type 1
> :PCI: Probing PCI hardware

It's ugly and distracting and if this proposal goes anywhere, move the tag to 
end of the line.  Then your eyes can scan the output and the tools can scan
the end of the line.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: ISA hardware discovery -- the elegant solution

[Zwane Mwaikambo]

You haven't taken into consideration that not many distributions have
drivers in kernel, and in particular ISA device drivers. Namely because
ISA probes are ugly and require frobbing of memory in the vague hopes of
finding said device there. These probes may put ye old ISA device in a bad
state sometimes even hard locking your box, so chances are if the ISA
probe is in dmesg, the user explicitely decided to load the device. In
which case they already know what they have...

As an aside, i try not to use ISA and elegant in the same sentence ;)

Regards,
	Zwane Mwaikambo

Re: ISA hardware discovery -- the elegant solution

[Eric W. Biederman]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> I've been thinking about the hardware-discovery problem for ISA devices,
> and there may be an elegant solution.  It will take a number of small changes
> to the kernel sources, however.

An elegant solution is writing a program like kudzu and placing the
information it generates in a globally accessible place.  The problem
is that linux does really have a complete standard hardware database,
and until such a thing is built there are no short cuts, no easy methods
to get it.  And there probably never will be guaranteed unprivledged
user space access to the information.  The system administrator may
simply not want to let that information go.

The only thing that comes close to what you currently want is
devfs.

dmesg is for people.

As for ISA there is a reason even the enhance version that allows
software discovery is called Plug-and-Pray.


> My autoconfigurator's probe table now has a small number of tests than 
> do regexp matches against the dmesg log.  As is, this solution does not
> scale well, because each regexp has to be discovered by eyeball and then
> maintained in the table by hand.

ISA is not a software enumerable bus especially not for unprivledged
users.  And no amount of complaining will change that.  That is why we
have PNP ISA and PCI.

> But suppose the format of boot-time driver messages were standardized in a
> format that included their config symbol in a discoverable form?

If there was an ISA device in your example it might be interesting.

> With this change, generating a report on ISA hardware and other
> facilities configured in at boot time would be trivial.  This would
> make the autoconfigurator much more capable.  Best of all, the only
> change required to accomplish this would be safe edits of print format
> strings.

It sounds like what you want is an lsmod that lists compiled in
modules.

> I would be willing to generate a patch to implement this change.

Please don't until you understand the problem...

Eric

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Eric W. Biederman <ebiederm@xmission.com>:
> ISA is not a software enumerable bus especially not for unprivledged
> users.  And no amount of complaining will change that.  That is why we
> have PNP ISA and PCI.

But the kernel itself has to know how to probe and initialize these devices
at boot time, correct?  That information is implicitly exported via
/var/log/dmesg -- I'm simply suggesting that it be a little more explicit.

> > But suppose the format of boot-time driver messages were standardized in a
> > format that included their config symbol in a discoverable form?
> 
> If there was an ISA device in your example it might be interesting.

Some of the on-board devices on my Tyan Thunder are ISA.

> > With this change, generating a report on ISA hardware and other
> > facilities configured in at boot time would be trivial.  This would
> > make the autoconfigurator much more capable.  Best of all, the only
> > change required to accomplish this would be safe edits of print format
> > strings.
> 
> It sounds like what you want is an lsmod that lists compiled in
> modules.

Would that be feasible without root privileges in order to read kmem?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

[The disarming of citizens] has a double effect, it palsies the hand
and brutalizes the mind: a habitual disuse of physical forces totally
destroys the moral [force]; and men lose at once the power of
protecting themselves, and of discerning the cause of their
oppression.
        -- Joel Barlow, "Advice to the Privileged Orders", 1792-93

Re: ISA hardware discovery -- the elegant solution

[H. Peter Anvin]

Followup to:  <20020114034831.A5780@thyrsus.com>
By author:    "Eric S. Raymond" <esr@thyrsus.com>
In newsgroup: linux.dev.kernel
> 
> But the kernel itself has to know how to probe and initialize these devices
> at boot time, correct?  That information is implicitly exported via
> /var/log/dmesg -- I'm simply suggesting that it be a little more explicit.
> 

dmesg is lossy.  Don't assume it is complete.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> You haven't taken into consideration that not many distributions have
> drivers in kernel, and in particular ISA device drivers. Namely because
> ISA probes are ugly and require frobbing of memory in the vague hopes of

Red Hat for one basically avoids ISA probing in favour of user guidance. We
also use a standard kernel build and the more I think about this the more
I think Erik's tool is trying to be too clever and should simply build 
a complete kernel set for the right cpu with the root fs and root fs block
device built into it

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Eric S. Raymond wrote:


> With this change, generating a report on ISA hardware and other
> facilities configured in at boot time would be trivial.  This would
> make the autoconfigurator much more capable.  Best of all, the only
> change required to accomplish this would be safe edits of print format
> strings.


Better: create a /proc/driver and every driver will register in it.
This file can help some bug report (and not only autoconfigurator).

BTW, my new tests for:
   memory (request_mem_region)
   io port (request_region)
   irq (request_irq)
   dma (request_dma)
are nearly completes.
I think every ISA card should registers one of
these resources.
With the check of register_blkdev, register_chrdev
and miscdevices we should have a complete list of the
old ISA devices.
(this would detect only already detected devices,
but autoconfigure is not yet designed for bootfloppies
makers).

With such new test: no patch to kernel and nearly automatic
generation of probes.

Some patch are still welcome. I.e.:
some people with copy+paste have not changes the driver
string. A kernel patch will help distinguish the two drivers.
watchdog: to many driver register as 'watchdog' (or 'serial',
or 'ps2mouse'. This will create some difficulties to
autoconfigurators. A patch will help us (but it would break
other userspace tools?)

	giacomo

RE: ISA hardware discovery -- the elegant solution

[Michael Lazarou (ETL)]

> -----Original Message-----
> From: Eric S. Raymond [mailto:esr@thyrsus.com]
> Subject: ISA hardware discovery -- the elegant solution
> 
> 
> I've been thinking about the hardware-discovery problem for 
> ISA devices,
> and there may be an elegant solution.  It will take a number 
> of small changes
> to the kernel sources, however.
> 
> The kernel's device drivers have, of course, to include probe
> routines, and those hard-compiled in typically log the presence of
> their hardware to /var/log/mesg when it loads.  By scanning that
> file, we in effect get to use those probes.

Doesn't this mean that you would need a fully functional kernel
before you get to run the autoconfigurator?

Michael

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Michael Lazarou (ETL) wrote:

>>
>>The kernel's device drivers have, of course, to include probe
>>routines, and those hard-compiled in typically log the presence of
>>their hardware to /var/log/mesg when it loads.  By scanning that
>>file, we in effect get to use those probes.
>>
> 
> Doesn't this mean that you would need a fully functional kernel
> before you get to run the autoconfigurator?


Not a problem. Autoconfiguration is made to help configuring
the kernel, before to compile it. So you need a linux working
machine (actually you can cross-compile).

Our task is to allow user to compile a kernel, with the
needed drivers, without the non used drivers.

If you want a good running kernel image:
   check the kernels in your distribution.
If you want to compile a general running kernel:
   use the kernel sources in your distribution (
   with your distribution's .config), or compile
   the std kernel with your distribution's .config

If you want a working kernel to boot Linux in your

   old/new/non-x86 machine: check the installation
   note of your distribution. Use special kernel (from
   your distribution,...)

 

You see: different task needs different tools.
Maybe we can merge some problems, but how? why?

[I still have a working version of autoconfigure in
shell, if some "boot-floppies" people need some
of our detection.]

But for old ISA cards (and some newer laptop) there is
only one method to find the right *kernel*:
boot and try (and changing kernels, parameters,...)
[check: installation document and internet resources].

We don't want a boot and retry for our configuration,
so let use the (incomplete) infos from kernel.

	giacomo

Re: ISA hardware discovery -- the elegant solution

[Zwane Mwaikambo]

On Mon, 14 Jan 2002, Alan Cox wrote:
> Red Hat for one basically avoids ISA probing in favour of user guidance. We
> also use a standard kernel build and the more I think about this the more
> I think Erik's tool is trying to be too clever and should simply build
> a complete kernel set for the right cpu with the root fs and root fs block
> device built into it

I'm definately not a fan of automagic kernel configurations, there are way
too many variables. Frankly the way i see it distro kernels do a damn good
job as it is right now and i don't see anything wrong with going the RH
errata kernel style for upgrading kernels (ditto for Debian and their apt
kernel upgrades). All Aunt Tillie has to do is click on the update button.

Are ISA device questions really that much of a big problem? The way i see
it, the user would get flooded more with the plethora of PCI and USB
devices more than anything. Then again i might be missing the "Big
Picture" ;)

Regards,
	Zwane Mwaikambo

RE: ISA hardware discovery -- the elegant solution

[Michael Lazarou (ETL)]

> -----Original Message-----
> From: Giacomo Catenazzi [mailto:cate@debian.org]
> >>
> >>The kernel's device drivers have, of course, to include probe
> >>routines, and those hard-compiled in typically log the presence of
> >>their hardware to /var/log/mesg when it loads.  By scanning that
> >>file, we in effect get to use those probes.
> >>
> > 
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> 
> Not a problem. Autoconfiguration is made to help configuring
> the kernel, before to compile it. So you need a linux working
> machine (actually you can cross-compile).
> 
> Our task is to allow user to compile a kernel, with the
> needed drivers, without the non used drivers.

OK, well I guess I am a little confused.

If I hit an autoconfigurator button then I would expect a kernel that
will boot and know everything there is to know about my machine.

Without probing the hardware how will the autoconfigurator cope with 
the hardware changing underneath it?

Michael

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Michael Lazarou (ETL) wrote:


>>Not a problem. Autoconfiguration is made to help configuring
>>the kernel, before to compile it. So you need a linux working
>>machine (actually you can cross-compile).
>>
>>Our task is to allow user to compile a kernel, with the
>>needed drivers, without the non used drivers.
>>
> 
> OK, well I guess I am a little confused.
> 
> If I hit an autoconfigurator button then I would expect a kernel that
> will boot and know everything there is to know about my machine.


Actually there is no yet 'autoconfigurator button'.
I recommend to run a std configuration tool and to check
the configuration before the kernel build phase.

> Without probing the hardware how will the autoconfigurator cope with 
> the hardware changing underneath it?


We probe the hardware (but in a soft manner).
Better: we probe nothing, we ask kernel to give us the results
of already done kernel probes. Thus we never hang, we never crash
machine, no 10-15 reboots to install a new kernel.
The good news: this is nearly enought.

Linux is magic: it can do infinite loops in 5 sec, but also
it can configure automatically a new kernel without real hardware
probes!.

	giacomo

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> Doesn't this mean that you would need a fully functional kernel
> before you get to run the autoconfigurator?

Yes, but this was always true.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself a
reputation as a dangerous citizen these days is to go about repeating
the very phrases which our founding fathers used in the great struggle
for independence.	-- Attributed to Charles Austin Beard (1874-1948)

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Giacomo Catenazzi <cate@debian.org>:
> > With this change, generating a report on ISA hardware and other
> > facilities configured in at boot time would be trivial.  This would
> > make the autoconfigurator much more capable.  Best of all, the only
> > change required to accomplish this would be safe edits of print format
> > strings.
>  
> Better: create a /proc/driver and every driver will register in it.
> This file can help some bug report (and not only autoconfigurator).

That would be fine with me.  But wouldn't it involve adding a new
initialization-time call to every driver.
-- 
		<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

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Giacomo Catenazzi <cate@dplanet.ch>:
> >>Better: create a /proc/driver and every driver will register in it.
> >>This file can help some bug report (and not only autoconfigurator).
> > 
> > That would be fine with me.  But wouldn't it involve adding a new
> > initialization-time call to every driver.
> 
> I think we can add it automatically, modifing one of the
> the modules macros. (this works automatically only for
> trit symbols).

That would be OK.  I think there are *very* few drivers left that 
aren't modular.

> Hmm. IIRC there is a  big module/driver API (for modules) change
> in 2.5 programs (driver registration,...). In this case we should
> only modify the API before it will be effectivelly used, and
> the changes will go automatically in kernel...

This sounds encouraging.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Ideology, politics and journalism, which luxuriate in failure, are
impotent in the face of hope and joy.
	-- P. J. O'Rourke

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Eric S. Raymond wrote:

> Giacomo Catenazzi <cate@debian.org>:
> 
>>>With this change, generating a report on ISA hardware and other
>>>facilities configured in at boot time would be trivial.  This would
>>>make the autoconfigurator much more capable.  Best of all, the only
>>>change required to accomplish this would be safe edits of print format
>>>strings.
>>>
>> 
>>Better: create a /proc/driver and every driver will register in it.
>>This file can help some bug report (and not only autoconfigurator).
>>
> 
> That would be fine with me.  But wouldn't it involve adding a new
> initialization-time call to every driver.


I think we can add it automatically, modifing one of the
the modules macros. (this works automatically only for
trit symbols).
Hmm. IIRC there is a  big module/driver API (for modules) change
in 2.5 programs (driver registration,...). In this case we should
only modify the API before it will be effectivelly used, and
the changes will go automatically in kernel...

	giacomo

Re: ISA hardware discovery -- the elegant solution

[Eli Carter]

"Eric S. Raymond" wrote:
> 
> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> Yes, but this was always true.

And if the reason you are building a new kernel is that the old one is
mis-identifying some of your hardware? ;)

Could you maybe describe the problem you are trying to solve a bit more
clearly than "the hardware-discovery problem for ISA devices"?  If you
are trying to discover the ISA devices, but rely upon them having
already been discovered, what are you accomplishing?

Puzzled,

Eli
--------------------.     Real Users find the one combination of bizarre
Eli Carter           \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------

Re: ISA hardware discovery -- the elegant solution

[Wichert Akkerman]

In article <3C430E89.E65DCEDC@inet.com>,
Eli Carter  <eli.carter@inet.com> wrote:
>Could you maybe describe the problem you are trying to solve a bit more
>clearly than "the hardware-discovery problem for ISA devices"?  If you
>are trying to discover the ISA devices, but rely upon them having
>already been discovered, what are you accomplishing?

The problem is that it is simply not possible to identify ISA devices
if they aren't isapnp devices. The only thing you can do is try to
probe for them by poking at different addresses and checking what happens.
Unfortunately this can do any of three things: show that a piece of
hardware exists, show that it is not there or completely crash your
machine if another unpexpected piece of hardware happens to be at the 
place you are poking.

The best approach to doing ISA detection is ask the user which
devices he thinks he has installed and try looking for them while
praying bad things won't happen.

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: ISA hardware discovery -- the elegant solution

[Eric W. Biederman]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Eric W. Biederman <ebiederm@xmission.com>:
> > ISA is not a software enumerable bus especially not for unprivledged
> > users.  And no amount of complaining will change that.  That is why we
> > have PNP ISA and PCI.
> 
> But the kernel itself has to know how to probe and initialize these devices
> at boot time, correct?  That information is implicitly exported via
> /var/log/dmesg -- I'm simply suggesting that it be a little more explicit.

For ISA not necessarily.  It could simply be told that it was there.
/etc/modules.conf or it's compile time equivalent.
 
> > > But suppose the format of boot-time driver messages were standardized in a
> > > format that included their config symbol in a discoverable form?
> > 
> > If there was an ISA device in your example it might be interesting.
> 
> Some of the on-board devices on my Tyan Thunder are ISA.

I agree that ISA is a case.  I simply didn't see it.  And that was
my real point.  Usually we are pretty silent about most ISA devices in
dmesg, because of most of them are mandated by the PC architecture and
we just expect them to be there.
 
> > > With this change, generating a report on ISA hardware and other
> > > facilities configured in at boot time would be trivial.  This would
> > > make the autoconfigurator much more capable.  Best of all, the only
> > > change required to accomplish this would be safe edits of print format
> > > strings.
> > 
> > It sounds like what you want is an lsmod that lists compiled in
> > modules.
> 
> Would that be feasible without root privileges in order to read kmem?

Given that nothing in the linux world reads kmem... 

Honestly you have two separate problems.
Problem 1:  How do you find out all of the hardware you have, as root.
Problem 2:  How do you get that information as non-root.

Please try solving these problems separately.

Eric

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> That would be fine with me.  But wouldn't it involve adding a new
> initialization-time call to every driver.

man lsmod

Re: ISA hardware discovery -- the elegant solution

[Mr. James W. Laferriere]

	Hello All ,  And what mechanism is going to be used for an -all-
	compiled in kernel ?  Everyone and there brother is so enamoured
	of Modules .  Not everyone uses nor will use modules .
		Tia ,  JimL

On Mon, 14 Jan 2002, Alan Cox wrote:

> > That would be fine with me.  But wouldn't it involve adding a new
> > initialization-time call to every driver.
>
> man lsmod
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > That would be fine with me.  But wouldn't it involve adding a new
> > initialization-time call to every driver.
> 
> man lsmod

I couldn't make any sense at all out of this until your later posting
saying that compiled-in drivers are going away when initramfs comes in.
You might try being a *little* less terse...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Love your country, but never trust its government.
	-- Robert A. Heinlein.

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> 	Hello All ,  And what mechanism is going to be used for an -all-
> 	compiled in kernel ?  Everyone and there brother is so enamoured
> 	of Modules .  Not everyone uses nor will use modules .

For 2.5 if things go to plan there will be no such thing as a "compiled in"
driver. They simply are not needed with initramfs holding what were once the
"compiled in" modules.

Alan

Re: ISA hardware discovery -- the elegant solution

[Oliver Xymoron]

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
>
> Yes, but this was always true.

No it's not. You only need a kernel that can run your compiler.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> I couldn't make any sense at all out of this until your later posting
> saying that compiled-in drivers are going away when initramfs comes in.
> You might try being a *little* less terse...

why ? 8)

(and yes that was meant to be a joke)

Alan

Re: ISA hardware discovery -- the elegant solution

[Stephen Shirley]

Hi,
	If, as Alan described, you can depend on the distro's installation
	program to have automatically identified all the hardware possible,
	and for the user to have specified and additional (i.e. isa etc) 
	devices, then could not the autoconfigurator simply see what drivers 
	are currently in use (via /proc/devices etc), check
	/etc/modules.conf for any that don't happen to be loaded at the
	time, and use that info to configure the new kernel. Unless there is
	some new piece of hardware that the new kernel supports that is
	present (and isn't supported by the old one), if linux was installed
	properly, you now have all the info you need, no? This removes the
	need for the configurator to do any sort of probing, neither are
	root proviledges required. Anyway, that's all probably blatantly
	obvious etc, so I'll just be quiet now.

Steve
-- 
"My mom had Windows at work and it hurt her eyes real bad"

Re: ISA hardware discovery -- the elegant solution

[Andrew Pimlott]

On Mon, Jan 14, 2002 at 11:11:41AM -0500, Eric S. Raymond wrote:
> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> Yes, but this was always true.

I think the point people are getting at is:  If you're re-detecting
things that have already been detected, doesn't it seem you're going
about the problem the wrong way?

Most distributors need to solve essentially the same problem you're
solving (detect hardware and install drivers), but without compiling
a kernel (if only to spare the user the wait).  To the extent that
they are successful (and they will presumably put considerable
effort into it), your compile-time probes are superfluous--you're
better off piggy-backing on the distribution's hardware detection.
Eg, derive your .config from the modules the distribution has
decided to load, or--even simpler--just compile a kernel with the
same .config as the distributor's kernel, and let the boot-time
scripts take care of the rest.  The drawback is that this differs
across distributions--but see below.

Even if you can usually do a better job, you have two major
handicaps:  One, you may have to repeat questions that the
distribution already asked, annoying the user.  Two, if you ever
screw up something the distribution had working, the user will curse
you.

Which leads me to conclude that your compile-time autodetection,
while cool, is a dead-end as far as helping Cousin Billie (though I
do support the ultimate goal of letting him compile a kernel).
There are some scenarios where you win, but not enough IMO.

To correct this, retarget the project to solve the distributors'
problem.  Ie, add a back-end that specifies modules and module
options, instead of a kernel .config.  Assuming you do a good enough
job, and meet the distributor's other requirements (eg, running in
an install environment), then they will use your system for their
install-time hardware detection.  You can store the results in a
standard (across distributions!) format, which administrators will
love (and which can be used by various to-be-written utilities).
Finally, you can later use the same database for compiling a
"stripped-down" custom kernel.

Andrew

Re: ISA hardware discovery -- the elegant solution

[Tom Gilbert]

* Oliver Xymoron (oxymoron@waste.org) wrote:
> On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> 
> > Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > > Doesn't this mean that you would need a fully functional kernel
> > > before you get to run the autoconfigurator?
> >
> > Yes, but this was always true.
> 
> No it's not. You only need a kernel that can run your compiler.

It's already been pointed out that the autconfigurator requires a great
many in-kernel features and userspace utilities.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@linuxbrit.co.uk    |
  ^^-^^   `-------------------------------------------------------'