linux-kernel - Re: Rewriting floppy.c was Re: Free Linux Driver Development!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58cb370e0702010512j51cc2d06w6ffa6df12bbc99f6@mail.gmail.com>
Date:	Thu, 1 Feb 2007 14:12:22 +0100
From:	"Bartlomiej Zolnierkiewicz" <bzolnier@...il.com>
To:	"Andi Kleen" <ak@...e.de>
Cc:	"Greg KH" <greg@...ah.com>, "Adrian Bunk" <bunk@...sta.de>,
	"Roland Dreier" <rdreier@...co.com>, linux-kernel@...r.kernel.org
Subject: Re: Rewriting floppy.c was Re: Free Linux Driver Development!

On 31 Jan 2007 11:08:14 +0100, Andi Kleen <ak@...e.de> wrote:
> Greg KH <greg@...ah.com> writes:
> >
> > What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
> > that floppy.c is?  Do you want everyone just to run screaming from
> > kernel development never to be seen again?

floppy.c is not really that ugly or complicated...

It just needs some care:

* cleanup of the over-usage of macros (DP macro etc)
* DocBook documentation would be nice
* make debugging printks optional by using macros in a smart way
  (see libata code for examples)
* tracking and fixing current regressions

Once the above is done there would be more room
for the future cleanups and improvements like:

* using bios directly in copy_buffer()
  (or avoiding copy completely if possible - need somebody to look at code)
* map user pages instead of memcpy-ing them in fd_copy{in,out}()
* unifying/merging arch specific code into floppy.c (not sure of this one)
* smarter way to handle IRQs

floppy.c rewrite offers an unique chance to learn by practice
from doing simple tasks (macros cleanup) to more advances ones
(involving block layer mechanisms) up to really difficult ones
(IRQ/"actual work" handling methods).

I could help with reviewing patches in case anybody is interested
and have patience to deal with few days delays for reply.  However
please don't add me to MAINTAINERS as floppy diver maintainer.

:)

> Doing a from-scratch rewrite of floppy.c only supporting new
> hardware and no obscure formats ("newfloppy.c") would be an excellent
> newbie project imho.  This means for someone who is still pretty
> new, but wants to get their fingers wet with more complicated changes.
>
> Then over time (old-)floppy.c could be phased out.

* this is unlikely that we need to add support for new hardware
* by doing the rewrite from scratch we will lose changes history
  and possibility to easily track regressions
* for a long time we would have to deal with both drivers

This is just not worth it IMHO.

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