Messages in this thread | | | Date | Sun, 28 Jun 1998 11:10:00 +0200 (MET DST) | From | MOLNAR Ingo <> | Subject | Re: Thread implementations... |
| |
On Sun, 28 Jun 1998, Linus Torvalds wrote:
> The same is not true of any of the other cases for copying from one > source to another. Yes, I can imagine doing insanely clever things like > just copying skb's around from one socket to another, but it's by no > means obvious how to do it, nor whether it is a feature that I'd be > ready to support forever even if I had a initial implementation.
i think all these copyfd() variations are pretty robust regarding the future, as they represent some kind of caching architecture, but on a much higher scale. For example, an fd->socket operation is a 'writeback'. A socket->socket transfer is a 'writethrough', a socket->fd is a 'cache fill' operation. So whatever higher level caching scheme (obviously with multiple hosts) we will have, these basic operations will likely to survive. (or die a big death together with all the other related concepts)
the caches in question are the VM (memory containing information on which user-defined CPU routines can operate), kernel memory (central information container), disk(s) (mass persistant information container), and other hosts (complex but distant, information-producing entities) connected by some interface(s). The whole point being that this host should act as a complex information-producing entity too.
[sorry if the formulation is a bit extreme, but i wanted to avoid quickly outdated terms :)] These caches and basic operations between them are i think not likely to go away anytime soon. And fds act as simple IO-channel identifiers.
in short: sendfile() is cool.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |