Re: [PATCH] cowlinks v2

[Davide Libenzi]

On Sun, 21 Mar 2004, Jörn Engel wrote:

> 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. ;)

Yes, at that time I preferred to fall back to the caller open(2) if any 
error happened during the COW (a more picky implementation would simply 
bounce an error to the application). Look BTW that there is a difference 
between the error handling when you have an in-kernel solution or a 
completely userspace solution. If you push this inside the kernel you have 
at least to define a new open(2) flag and a new set of errors that might 
arise when doing the COW. You are basically changing the open(2) API. You 
have also to "teach" apps to use the new flag, since obviously you cannot 
make COW a default behavior. The fl-cow approach let you define a set of 
paths where you want COW to happen (in my case typically /usr/src/lk), and 
only apps writing to hard-linked files inside such path gets COWed. The 
open(2) API does not change. OTOH there is the LD_PRELOAD trick that is 
weak alias dependent.



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