On 01/02/07, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
quoted text
> On 31 Jan 2007 11:08:14 +0100, Andi Kleen <ak@suse.de> wrote:
> > Greg KH <greg@kroah.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@gmail.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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/