Re: Device detection?
On Mon, 15 Mar 1999, Bruce Sass wrote:
> On Sun, 14 Mar 1999, Jonathan P Tomer wrote:
>>>checkpointing doesn't have to thrash the harddisk. consider this -- if you
>>>have a program that flushes output to disk for each line it writes to a file,
>>>does it thrash the harddisk?
>>>
>>>checkpointing is needed for lots of apps... it doesn't necessary cause any
>>>thrashing.
>>
>>windows checkpointing thrashes because they explicitly turn off caching
>>and writes after each device tested for. that's a lot of devices, and
>>it's very quick to test for each -- quicker than it is to write the
>>checkpoint info. but they decided it's worth it in order to have
>>bulletproof autodetection. it's not, imho.
>
> Maybe it is because hardware hackers are scarce around here,
> or maybe it is just too hairy or even impossible to implement...
>
> Is there any non-volatile memory that can be used during an
> installation, even if that means saving and then restoring the contents
> automatically when the system is stable[1] (or via the rescue disk or
> native system if the installation is aborted)?
I know lots of people on this list already know all of this and I'm
probably going to be tarred and feathered for what follows, but I'd like
to just tie up all the loose ends that are flying around here, and to
perhaps put across a more balanced opinion.
I like the windows autodetection scheme. I like the fact that I am given
the choice of whether to run it initially and I like the ability to tune
what devices/types of devices are probed for. I know for a fact I would
miss most of the less obvious devices (e.g. motherboard features - have
you ever looked down the bottom of the Win95 system devices list? I didn't
know I had paid money for most of those things :)
Given that having autodetection is good (I am not saying that it should be
the *only* way to do it, but in conjunction with manual setup it seems to
be the best option we have) we *have* to use checkpointing to make sure we
can recover from a hardware hang if it occurs. If we don't then we can't
complete the autodetection procedure. Checkpointing every n devices could
cause valid devices to be missed and should therefore probably be avoided.
Basically it boils down to having to checkpoint for every device.
While checkpointing, the data must be written back to the *disk* every
time a test is completed; caching is not an option. If the machine
crashes as the result of a hardware probe then you cannot guarantee that
any unwritten data will be written back to the disk. If the checkpoint on
the disk isn't current when we come back to the autodetection after
rebooting we will hit the same problem again.
I am very wary about using the non-volatile ram on the motherboard to
store the checkpoint information. I think that it is the kind of move
that could cause problems. It is not that I am afraid to get too close to
the hardware, just that I don't believe this to be the way to write a
robust autodetection routine when there are other options available.
Encapsulating the entire procedure by storing the checkpoints inside our
own operating system file space seems like a much simpler idea.
This looks very similar to the scheme that Windows uses at present, but
there are some possible improvements that we could make to this basic
pattern. By loading the drivers into memory/ensuring they are buffered en
mass before beginning the autodetection you could cut down disk activity
during the autodetection itself.
That said, I do think that hard drive noise during the autodetection
really is a trivial complaint if it reduces the amount of my time it takes
to set up the system. I think we would warm to the Windows scheme more if
we actually *knew* what it was doing (bring out the free software
banners...) and why that progress meter always seems to get to about 95%
before halting for a minute and then continuing :) I think we are all
just a little bit upset at the idea of mimicking a Microsoft program. We
really have to overlook that if we want Debian GNU/Linux to be the best.
Is anyone currently writing a unified tool to do this?
Matt
\\\\///// Matt Kern Tel: (01223) 366290
| | Matt.Kern@pobox.com http://xanadu.pet.cam.ac.uk/~mwk20/
| O O |
| L | If I had better tools, I could more effectively
| \__ | demonstrate my total incompetence.
\_____/
Reply to: