On Sun, Mar 14, 1999 at 05:45:34PM -0500, Randolph Chung wrote:
> So to sorta summarize, this is possibly something we want to do, right? The
> approach would be something like this:
>
> 0) On a machine with windows installed, maybe look at the registry to see what
> devices we can find
We just had an interesting argument about this one on irc. I think the
outcome was that we couldn't rely on this because windoze detect is
somewhat broken. I disagree because you would almost certainly have
corrected windoze' opinions about your hardware if they were wrong. In
any event, it should not be done as step 0.
> 1) On a PCI system, scan for PCI id's and pick up devices. should be relatively
> safe
> 2) Scan for PnP devices
These are probably all we really need do. It's been argued (see above
reference to irc) that if people have legacy hardware they know about it.
It's only the automagic stuff they would expect to be done for them.
This much I think is almost essential anymore. Note 2 should be
prepended with "On an ISA system, " Non-i386 machines usually don't have
ISA slots, other than some Alphas. I believe however non-i386 machines
with ISA slots use a PCI-ISA bridge like the one used on PCI i386
machines. If I'm right about that (please someone correct me if I'm not)
then detecting the ISA bus is pretty easy: if the machine is PCI look
for the ISA bridge. If it's not PCI, is it an i386?
> 3) io-port scan for legacy devices
As noted above, legacy hardware owners PROBABLY know what they have. If
they don't, well they should. => Of course what is crossing my mind
right now is legacy 486 freebees. These usually don't come with
manualrs. There's no way without the manuals to know what is built on to
the board, usually this includes legacy video, I/O, sometimes sound,
occasionally an addon modem.[1]
> 4) Scan for SCSI/ATAPI devices
At this time SCSI/IDE drivers must be compiled in. I'd like this to
change though. It should be possible to append a driver to the kernel's
image file, possibly update info in the kernel image (similar to what
rdev does) and have the modules attached to the kernel in this manner to
be loaded on startup.
This would be a Good Thing. You take a kernel image with just about
everything but the floppy driver (even that possibly) as modules. You do
the detection thing and figure out what modules _including_ IDE and SCSI
are needed. Anything that is needed to mount the root fs can just be
attached to the kernel and it'll be as if you compiled it in for all
intents and purposes of getting the machine running.
I'm still working out in my head how to do this. Other people seem to
think it's a good idea too. =>
> 5) Allow users to manually add/drop devices
>
> All the while, we'll need to keep some type of a checkpoint log, maybe not
> writing to disk for each device, but do them in blocks.
Why not start by asking them what kinds of hardware they would like to
detect? Some types of cards are more likely break stuff looking for them
than others. I'd break it down into device category. Things that come
to mind are network cards, SCSI cards, serial/modems/input devices,
parallel devices, sound cards, ....
No we can't overlook parallel devices. Too many people have them these
days. Fortunately the ones that are supported are fairly standardized
these days.
We shouldn't forget bus rodents and since we look for rodents on the
serial ports anyway why not make a note of what serial ports we find, if
there happens to be a modem attached to them, and what speed/init works
best with it. Code for this is probably going to end up a cross between
gpmtest and wvdialconf. =>
Something as yet unadressed, what do we do with the info once we have it.
I suppose we could dump the info we find in /etc/hwprobe/* or something
like that. Maybe /etc/hwprobe/cdroms would include how many cdroms the
probe found, data about each one, and the one that's considered the
"default".. I'd welcome other ideas or more thoughts about this idea.
I'm not sure it's the right way to do things but I'm also not sure it's
the wrong way either.
---
[1] In fact I have such a system. No manuals, 486SX/33, Packard Bell.
Not yet been booted. Here's what I know:
* 486SX/33 (probably not upgradable)
* Integrated IDE/IO - 1P, 1S, 1G, PS/2 keyb/rodent
* Modem
* Onboard video
* 1 72 pin SIMM socket
Stuff I don't know (but can guess)
* That serial port, it's almost certainly at 3F8/IRQ4
* That modem, it's probably 14400, most likely at 2F8/IRQ3
* There's probably 4 megs onboard RAM
* The video is probably WD or Trident
* The BIOS is probably NOT y2k happy
Linux should be able to tell me all of that at least. In this case
the only legacy detection would be the video driver. Detecting
legacy sound cards would be nice too I suppose but I don't have one
in this thing. Now my actual working machine has a legacy sound
card, but alsa detects that just fine and I know the IRQs and stuff
anyway...
--
Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First!
-------------------------------------------------------------------------
World Domination, of course. And scantily clad females. Who cares if
its twenty below? -- Linus Torvalds
Attachment:
pgpPLjahsBMPy.pgp
Description: PGP signature