Re: [PATCH] cowlinks v2

From: Davide Libenzi
Date: Sun Mar 21 2004 - 19:27:11 EST


On 21 Mar 2004, Eric W. Biederman wrote:

> Jörn Engel <joern@xxxxxxxxxxxxxxxxxxxx> writes:
>
> > On Sun, 21 March 2004 09:59:39 -0800, Davide Libenzi wrote:
> > >
> > > When I did that, fumes of an in-kernel implementation invaded my head for
> > > a little while. Then you start thinking that you have to teach apps of new
> > > open(2) semantics, you have to bloat kernel code a little bit and you have
> > > to deal with a new set of errors cases that open(2) is not expected to
> > > deal with. A fully userspace implementation did fit my needs at that time,
> > > even if the LD_PRELOAD trick might break if weak aliases setup for open
> > > functions change inside glibc.
> >
> > 209 fairly simple lines definitely have more appear than a full
> > in-kernel implementation with many new corner-cases, yes. But it
> > looks as if you ignore the -ENOSPC case, so you cheated a little. ;)
> >
> > No matter how you try, there is no way around an additional return
> > code for open(), so we have to break compatibility anyway. The good
> > news is that a) people not using this feature won't notice and b) all
> > programs I tried so far can deal with the problem. Vim even has a
> > decent error message - as if my patch was anticipated already.
>
> Actually there is... You don't do the copy until an actual write occurs.
> Some files are opened read/write when there is simply the chance they might
> be written to so delaying the copy is generally a win.

What about open+mmap?



- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/