RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy

[Hans de Goede]

Hi,

On 04/12/2010 11:06 PM, Kyle McMartin wrote:

<snip>

>>> PNP only reports the presence of the controller, not
>>> the drive.
>>>
>>
>> Wrong again, on most machines the presence of the PNP0700 id in the PNP data
>> depends on the setting of the floppy drive type in the BIOS, set it to None
>> and PNP0700 id goes away.
>>
>
> No, it's just like everything else. This is how the BIOS /should/ work,
> theory and practice are seldom similar. This bit Dave, and it bit me on
> all my machines, across a variety of vendors.
>

This is how the BIOS actually works in my experience across quite a large number
of machines. Did you actually verify the floppy was listed as not being present
in the CMOS setup on all those machines? One reset to defaults will put it back
at 1.44 MB.

Note that AFAIK windows relies on this working properly too, so I would be
surprised if a lot of machines got this wrong (sure some will have gotten it
wrong).

Also I find it a bit strange that we now default to making properly working
hardware not work out of the box (and yes people still use floppies), so
as to avoid a boot delay on buggy hardware ?

That very much seems like the other way around then how things should be.

>> Erm, you *completely* failed to respond to my upstream argument, if this is
>> as clear cut a decision as you make it, why don't you take it upstream ?
>>
>> This whole discussion really is quite simply, there are 3 options here:
>>
>> 1) floppy driver autoloading on pnp info is a bad idea ->
>>     take it upstream
>>
>> 2) this is a gray area ->
>>     let not deviate from upstream, discuss upstream
>>
>
> Upstream is irrelevant. They don't make an OS, we do.
>

Yes, so that is why we always say that any patches going into the Fedora
kernel should either already be upstream, or have a clear path of being
included upstream. I don't see how this patch is so special that that
rule all of a sudden does not apply. Esp. as this is not as clear a
case as you seem to think it is (and again if it is as clear a case,
take it upstream).

>> 3) floppy driver autoloading is fine, people with problems need
>>     to be educated to properly configure their BIOS
>>
>
> This is ridiculous.

Really statements like "ridiculous" and "irrelevant" (nor the "extremely"
below), do not help in having a constructive discussion about this.

Again lets talk numbers here. Having a discussion like this on anything
but numbers is really rather meaningless.

I'm sure we all have access to a wide variety of machines, so lets actually
see what happens to the PNP0700 id when the floppy gets marked as disabled
in the BIOS, you can easily find this out, by making sure the floppy is
disabled in the BIOs and then doing:
cat /sys/bus/pnp/devices/*/id

If PNP0700 is not listed, the BIOS is behaving properly and dropping the
die-floppy-die patch won't affect the machine.

Here are my numbers:
Asus M2N SLI deluxe: PNP0700 disappears
Abit KV8 Pro:        PNP0700 disappears (*)
Asrock AM2NF3-VSTA:  PNP0700 disappears
Compaq Evo N600C:    PNP0700 disappears
Dell Latitude E6400: no floppy config possible, laptop, no PNP0700
MSI Wind u100:       no floppy config possible, laptop, no PNP0700

*) After setting floppy controller to disabled in a separate config screen,
    simply setting the attached floppy type to None does not work.

>> Also note that anaconda is autoloading the floppy driver on every install,
>> so if it would really be the cause of a lot of problems, we (the anaconda
>> team) would have been overwhelmed by bug reports about this by now, which
>> surprise, surprise we are not.
>>
>
> The issue is that probing the controller with no drives attached causes
> extremely long boot delays. That's why we removed the module aliases.

Again numbers please. I just did "modprobe floppy" on my floppy less main
workstation, and it took 2 seconds. Also aren't we loading modules in
parallel now a days ?

Regards,

Hans