[lkml]   [2001]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectLearn from minix: fork ramfs.
(Argh!  Linus replies to my post and my cc: to the linux-kernel was to Teach me to post on three hours of sleep, it's like
getting a hole-in-one with nobody around...)

Linus said in Re: Patch (repost): cramfs memory corruption fix

> I wonder what to do about this - the limits are obviously useful,
> as would the "use swap-space as a backing store" thing be. At the
> same time I'd really hate to lose the lean-mean-clean ramfs.

So fork ramfs already. Copy the snapshot you like as an educational
tool, call it skeletonfs.c or some such, and let the current code evolve
into something more useful.

Seems to me a dude named Andrew was in a similar situation a decade or
so back, and decided to resist all change in the name of having a clear
educational example. Patch pressure built up past the "reimplementation
from scratch threshold event horizon thingy" (the tanenbaum-torvalds
barrier), at which point the code forked under its own weight anyway.

Saves a lot of bother to do it now, if you ask me. You'll wind up with
a new ramfs one way or the other. People will keep writing it as long
as it's not there. (The whole "why climb mount everest" thing, you

I could, of course, be totally wrong about this...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.065 / U:2.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site