Re: File copy system call proposal

[Jakob Østergaard]

On Thu, Dec 20, 2001 at 02:38:50PM +0100, Svein Ove Aas wrote:
> On Thursday 20. December 2001 11:09, Pavel Machek wrote:
> >
> > They need to get a clue. No need to work around their bugs in kernel.
> >
> > Anyway copyfile syscall would be nice for other reasons. (cp -a kernel
> > tree then apply patch without waiting for physical copy to be done
> > would be handy).
> > 								Pavel
> 
> Never mind that it might save a great deal of space...
> I often operate with three/more different kernel trees, but the differences 
> are often trivial.
> If the VFS created a COW node when I use cp -a I would, obviously, save a 
> great deal of space; this goes for numerous other source trees too.
> 
> Now there's a real world example for you.

No graphical file manager would use it - how would you show progress
information to the user when coping a single huge file ?

So, someone might hack up a 'cp' that used it, and in a few years when
everyone is at 2.4.x (where x >= version with copyfile()) maybe some
distribution would ship it.

Take a look at Win32, then have it. Then, look further, and you'll see
that they have system calls for just about everything else.  It's
a slippery slope, leading to horrors like CreateProcess() which takes
TEN arguments, where about half of them are pointers to STRUCTURES.

I'm not saying that adding copyfile() would take us there immediately,
but we'd be taking the direction, when you can get about all the speedup
with mmap()+write() or the likes anyway.

Just my 0.02 Euro

-- 
................................................................
:   [e-mail]   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............: