> Well, it's possible, but somewhat ugly. The real objection
> I can see is that if you're optimizing this by, say, doing
> DMA directly between the devices you may not actually have
> the data to hand back to the caller or indeed know very
> much about how much data you actually wrote out.
No. As you have to check the 'number of bytes to copy' limit, you
certainly have to know how much did you already transfer. Anyway, without
this you cannot have non-blocking copy which breaks traditional UNIX
semantics of file operations.
> This is consistent with write(2), though. As I understand
> it[*], if write returns an error, then under some circumstances
> you are not guaranteed that none of the data was written.
I've never said we should return byte count in case of _error_. Actually,
I proposed returning errno instead of byte count in such cases.
> > It would be better to allow selecting offsets in both source and destination
> > files.
>
> What's wrong with lseek? Perhaps you misunderstand -- copy
> is just a replacement for a loop with read + write -- so it
> works from the current file position (if, indeed, the fds
> refer to files at all).
You can save a lot of syscalls by feeding file offsets directy to copy() instead
of calling up to two lseek()s per copy.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
main(){char *s="main(){char *s=%c%s%c;printf(s,34,s,34);}";printf(s,34,s,34);}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu