On Sun, Mar 14, 1999 at 09:20:35PM -0500, Randolph Chung wrote:
> > 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.
>
> why's that? the idea is that if, after this phase, we've picked up all the
> hardware, then there's no point in proceeding with the rest of the stuff
> (which may hang)
I've been mulling this over and I agree with those on irc, we should stay
clear of the registry. Not for their reasons but rather for some sense
of pride. Not to mention the amount of PR damage that could be done by
it...
> > 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?
>
> i would think we have much more reliable ways of telling whether a machine
> is i386?
You misread me. Is there an ISA bus? Well, is this machine PCI? If
yes, we can look for a PCI-ISA bridge. If it's an i386 non-PCI machine,
it has an ISA bus. I don't know of ISA being used without PCI on
non-i386 machines.
> > 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]
>
> Since step 3 is the most dangerous, we should probably do something like
> this: do step 0, and show what we have. stop if nothing else needs to be
> detected. if user wants to continue, do steps 1 and 2, then again stop and
> ask if user wants to continue. then do step 3. in the spirit of
> configurability, all this should be optional, of course.
I'd do your 1 and 2 first. PCI should be totally harmless. PnP should
not break anything if you have an ISA bus (see above) Then we can
consider doing stuff like reading other sources for config info or
probing ports.
> > 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.
>
> what do you mean by this? are you just refering to the install disks? most
> certainly, if a user were to upgrade his system and want to run the
> detection process again, there's no reason to not detect scsi/atapi devices
> that might have been added. there's no reason why drivers for Zip drives and
> scsi/atapi cdroms shouldn't be loaded as modules.
Take kernel. Compile EVERYTHING as modules. Build kernel and modules as
initrd along with the stuff to detect hardware. Your hardware gets
detected and modules needed to boot the kernel are somehow tacked onto
the kernel so they're loaded immediately, allowing root FS to be mounted.
This allows us to build a kernel without all the network and SCSI drivers
in it.
> > 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.
>
> as above, i was thinking more on the lines of peripheral hardware like zip
> drives and CD-ROMs. In a certain sense, harddisk drivers should be compiled
> in.
Have you counted the number of SCSI card drivers lately?
> > > 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, ....
>
> that's a good idea too -- one thing though. Debian has a certain tendency to
> make things so configurable that it becomes confusing/difficult for a
> newcomer. it's good for things to be configurable but there must be a
> balance so it doesn't become overwhelming.
Do you have SCSI?
Do you have a sound card?
Do you have a network card?
Shall I look for modems, etc in your machine?
These are not overwhelming questions for someone with a fraction of a
clue. => Putting them in a nice checkbox-type menu screen with help
available should make it even less overwhelming.
> > 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.
>
> that's what i was thinking too.. then all our config tools can use the info
> in there.
That's the general idea, yeah.
--
Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First!
-------------------------------------------------------------------------
"Actually, the only distribution of Linux I've ever used that passed the
rootshell test out of the box (hit rootshell at the time the dist is
released and see if you can break the OS with scripts from there) is
Debian."
-- seen on the Linux security-audit mailing list
Attachment:
pgpMkjFwMb8wR.pgp
Description: PGP signature