linux-kernel - Re: [PATCH -mm] [2/2] Add the Elevator I/O scheduler

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0608071601270.27060@gandalf.stny.rr.com>
Date:	Mon, 7 Aug 2006 16:07:02 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Daniel Phillips <phillips@...gle.com>
cc:	Dave Jones <davej@...hat.com>, 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



On Thu, 3 Aug 2006, Daniel Phillips wrote:

> 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?

No he's just pointing out that it goes on and on and on...

> 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?
>

Yes a "see Documentation/" line would be much more appropriate.

-- Steve

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