Re: PROBLEM: floppy motor spins when floppy module not installed

[John Bradford]

> > > Yes, and I recall we agreed to disagree where the FDC stop must
> > > be put, but we both agreed that it must be stopped. I still contend
> > > that since the Linux startup code takes control away from the BIOS,
> > > it's that codes responsibility to turn OFF things that the BIOS
> > > might have left ON.
> >
> > Well, on a practical level, yes, I agree with you, it is the easiest
> > way to solve the problem.
> >
> > On a technical level, I still think that the BIOS configuration is
> > broken if it leaves the floppy motor on, on a system running a kernel
> > without the floppy code compiled in.
> 
> Hmmm. The BIOS doesn't know that you have a kernel without any
> floppy code.

No, but the user does, and if the machine in question boots fast
enough that interrupts are disabled less than two seconds after the
last BIOS floppy access, they should currently avoid configuring the
BIOS in such a way that it accesses floppy drive if there is not going
to be any code to turn it off, which currently means having floppy
support compiled in, (or as a module).

> The BIOS also doesn't know that its timer queue
> is going to be destroyed by the data (code) that it's properly
> reading from some disk. All it knows is that every time the
> floppy is accessed, the motor must be turn ON before access
> and must be turned OFF two seconds after the last access. Since
> it doesn't know when the last access will be (it doesn't know the
> future), it resets a timer-variable upon every access. The timer-
> queue bumps the variable and if it gets to zero, turns OFF the
> FDC motor.
> 
> The BIOS code is properly doing its job. When control is
> taken away from the BIOS, the code that took control

The code that took control is the bootloader, which may never load a
Linux kernel.  Imagine a theoretical future bootloader which disabled
interrupts, thereby stopping the two second floppy motor timeout, and
offered things such as a serial console, monitor, or other diagnostic
features.

> must
> tie up any loose-ends that the BIOS wasn't able to finish.

Possibly, but I still consider the BIOS configuration broken if there
are infact any loose-ends to tie up.

> It's not the job of the boot-loader because it didn't alter
> the BIOS in any way. It used the BIOS to put the kernel in
> it's correct place. Then it gives control to the kernel
> code. It's that kernel code that takes control away from
> the BIOS. It's the responsibility of that kernel code
> to handle the consequences of doing that.

At the end of the day, though, I agree that it's the best way to fix
it, but we shouldn't convince ourselves that it's particularly
elegant.

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/