On Wed, Jan 19, 2005 at 09:14:33AM -0800, Linus Torvalds wrote:
> I think you are perhaps confused about the fact that what makes this all
> possible in the first place really is the _pipe_. You probably think of
> "splice()" as going from one file descriptor to another. It's not.
You seem to have misunderstood the original proposal, it had little to do
with file descriptors. The idea was that different subsystems in the OS
export pull() and push() interfaces and you use them. The file decriptors
are only involved if you provide them with those interfaces(which you
would, it makes sense). You are hung up on the pipe idea, the idea I
see in my head is far more generic. Anything can play and you don't
need a pipe at all, you need
struct pagev {
pageno page; // or whatever the type is to get the page
u16 offset; // could be u32 if you have large pages
u16 len; // ditto
};
struct splice {
pagev pages[];
u8 gift:1;
u8 loan:1;
};
You can feed these into pipes for sure, but you can source and sink
them from/to anything which exports a pull()/push() entry point.
It's as generic as read()/write() in the driver object.
I never proposed restricting this to file descriptors, that makes
no sense. File descriptors are nothing more than something which
gets you to the underlying object (socket/file/pipe/whatever) and
lets you call into that object to move some data.
See how more generic that is? Pipes are just one source/sink but
everything else needs to play as well. How are you going to
implement a socket sending data to a file without the VM nonsense
and the extra copies?
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
