From: philip@warpmail.net (Philip K.)
To: Denis Efremov <efremov@linux.com>
Cc: moritzm.mueller@posteo.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@i4.cs.fau.de
Subject: Re: [PATCH] floppy: hide invalid floppy disk types
Date: Mon, 09 Dec 2019 18:30:18 +0100 [thread overview]
Message-ID: <878snle79x.fsf@bulbul> (raw)
In-Reply-To: <04f0dfb9-d25a-d9a3-74cd-538165a8bfa2@linux.com> (Denis Efremov's message of "Mon, 9 Dec 2019 20:04:32 +0300")
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
> Hmm, I would say that driver blacklisting is a more proper solution in
> this case. I doubt there are people with this issue and real floppy drives
> in their setup. Altering the default driver's initialization scheme seems
> superfluous to me.
As long as major distributions like Ubuntu ship the floppy module, there
are enough people who could be affected by this peculiar behaviour.
While I agree that blacklisting the module would be more elegant, I
still think that a patch that goes in this direction could help more
people, especially those who don't want or cannot solve kernel-related
issues.
> This will force users (if there are ones) who depends on this behavior
> to rebuild the kernel. blacklisting doesn't require kernel rebuild.
Are there floppy disks of unknown types? Our patch is intentionally
conservative: We won't hide false negatives. If the motherboard reports
an non-existent disk
If you're ready to think about it, we could consider extending the patch
to un-register the device if it can recognise that it's (probably) not
real. In our case, for example, fdisk reported that fd0 had a size of
4k, something think is a strong indicator that something's not right.
Alternatively, we could look into what the comment
/* FIXME: additional physical CMOS drive detection should go here */
would imply. This particular bug can only affect fd0 and fd1, so if we
spent some more time, we could find something.
--
With kind regards,
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2019-12-09 17:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-08 19:45 [PATCH] floppy: hide invalid floppy disk types Moritz Müller
2019-12-08 20:16 ` Denis Efremov
2019-12-09 9:32 ` [PATCH v3] " Moritz Müller
2019-12-09 17:03 ` Denis Efremov
[not found] ` <87h82ajzqd.fsf@bulbul>
2019-12-09 17:04 ` [PATCH] " Denis Efremov
2019-12-09 17:30 ` Philip K. [this message]
2019-12-09 0:32 ` kbuild test robot
2019-12-09 0:32 ` kbuild test robot
-- strict thread matches above, loose matches on Subject: below --
2019-12-08 16:59 Moritz Müller
2019-12-08 17:35 ` Randy Dunlap
2019-12-08 19:01 ` kbuild test robot
2019-12-08 19:01 ` kbuild test robot
2019-12-10 5:07 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878snle79x.fsf@bulbul \
--to=philip@warpmail.net \
--cc=efremov@linux.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@i4.cs.fau.de \
--cc=linux-kernel@vger.kernel.org \
--cc=moritzm.mueller@posteo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.