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]

Date:	Thu, 1 Feb 2007 14:22:51 +0100
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Bartlomiej Zolnierkiewicz" <bzolnier@...il.com>
Cc:	"Andi Kleen" <ak@...e.de>, "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 01/02/07, Bartlomiej Zolnierkiewicz <bzolnier@...il.com> wrote:
> 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.
>

Good points. I'll try cleaning up the existing driver instead of doing
a complete rewrite.

-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
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/