On Tue, 6 Jun 2000, Hans Reiser wrote:
> > The main point are
> > the common hooks. In the early day of ext3/reiser every fs had its own
> > patches to buffer.c which usually conflicted. reiserfs solved it by
> > copying huge chunks of buffer.c into buffer2.c and using that. ext3
> > still used some hooks in buffer.c directly last time I checked. The code
> > duplication in buffer2.c is certainly bad and could take some
> > ``common hooks''. Maybe Linus thinks that's ok, Alan apparently thinks it
> > is not, we'll see how it ends.
>
> I am simple, give me a hook and I'll use it, if not I'll try to avoid making
> demands of others to change their code to accomodate me, and I'll do that by
> using code duplication. Give us a license to change buffer.c code to be more
> general and we will.
A license? buffer.c is GPLed, surely, along with the rest of the kernel.
What's the problem?
> > Another issue is the hook needed to tell the journal
> > about memory pressure (this all has nothing to do with the VFS)
>
> Why shouldn't it be a VFS operation?
That sounds like a good idea. Actually, a system-wide notification
mechanism would be even nicer, so you could just register a "memory
pressure high" handler, and be notified whenever the kernel is running
short on RAM.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:25 EST