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, 03 Aug 2006 18:28:33 -0700
From:	Daniel Phillips <phillips@...gle.com>
To:	Dave Jones <davej@...hat.com>
CC:	Nate Diller <nate.diller@...il.com>, Andrew Morton <akpm@...l.org>,
	Jens Axboe <axboe@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mm] [2/2] Add the Elevator I/O scheduler

Dave Jones wrote:
>  > +/****************
>  > + *
>  > + * Advantages of the Textbook Elevator Algorithms
>  > + *  by Hans Reiser
>  > + *
>  > + * In people elevators, they ensure that the elevator never changes
>  > + * direction before it reaches the last floor in a given direction to which
>  > + * there is a request to go to it.  A difference with people elevators is
>  > + * that disk drives have a preferred direction due to disk spin direction
>  > + * being fixed, and large seeks are relatively cheap, and so we (and every
>  > + * textbook) have a one way elevator in which we go back to the beginning 
>  > > blah blah blah..
> 
> This huge writeup would probably belong more in Documentation/

Hi Dave,

Surely you did not mean to characterize his documentation as blather?  It seems
to be of very good quality, we need to encourage that level of diligence.  As
far as moving it to Documentation goes, my immediate reaction is I sure do like
it when the coder cares enough about my understanding of what he's doing to
put such effort into trying to make sure I understand what he's doing and why
he's doing it.  Having it right in the code removes a level of indirection when
reading that might make the difference between me reading and not reading the
documentation, which in turn might make the difference between understanding and
not understanding the code.  Agreed it's a bit much at least all in one piece.

Maybe precis the in-line documenation and move the greater literary effort to
Documentation, with the requisite "see Documentation/" line?

Regards,

Daniel
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ