On 1/8/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 7 Jan 2005, Oleg Nesterov wrote:
> >
> > If i understand this patch correctly, then this code
> >
> > for (;;)
> > write(pipe_fd, &byte, 1);
> >
> > will block after writing PIPE_BUFFERS == 16 characters, no?
>
P.S. Not to reply to myself... 8-) I took some liberties with that
description.
STREAMS doesn't, to the best of my knowledge, have the cleanup hook stuff.
That was
me folding your issues (direct PCI device buffers etc) from this thread on top
of the
basic skeleton of STREAMS to broaden the
Howdy,
The below (sorry about the Outlook style includes, work _requires_ outlook 8-()
is
why I previously mentioned the STREAMS implementation from SVR4 (and so Solaris
etc).
Every interface point has a pointer to its peer, a pair of queues and a put()
routine. Every message is in two or more
On Wed, 19 Jan 2005, Larry McVoy wrote:
>
> 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?
Heh. This is e
[EMAIL PROTECTED] wrote:
> 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 t
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 hav
On Wed, 19 Jan 2005, Larry McVoy wrote:
>
> I think you are going to regret making splice() a system call, it shouldn't
> be, you'll find cases where it won't work. Make it a library call built
> out of pull() and push()
Actually, if you look at my current (ugly) test-patch, the one part of it
I think you are going to regret making splice() a system call, it shouldn't
be, you'll find cases where it won't work. Make it a library call built
out of pull() and push(), see my original postings on this and you'll
follow the logic. Making splice a system call is like putting ftp
into the ker
Hi Linus,
Linus Torvalds wrote:
> +static long do_splice_from(struct inode *pipe, struct file *out, size_t len,
> unsigned long flags)
> +static long do_splice_to(struct file *in, struct inode *pipe, size_t len,
> unsigned long flags)
> +static long do_splice(struct file *in, struct file *out,
On Fri, 14 Jan 2005, Linus Torvalds wrote:
>
> So I don't think you'll get _exactly_ what you want for a while, since
> you'd have to go through in-memory buffers. But there's no huge conceptual
> problem (just enough implementation issues to make it inconvenient) with
> the concept of actually
In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>On Sat, 15 Jan 2005, Alan Cox wrote:
>>
>> Alan Cox (the other Alan Cox not me)
>
>Oh no! You guys are multiplying!
http://www.imdb.com/name/nm0184893/
Mike.
-
To unsubscribe from this list: send the line "unsubscribe
On Sat, Jan 15, 2005 at 04:12:27PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 15 Jan 2005, Alan Cox wrote:
> >
> > Alan Cox (the other Alan Cox not me)
>
> Oh no! You guys are multiplying!
>
> Run! Run for your lives!
It's been said for a while now that Alan is really a supercomputing
cluster
On Sat, 15 Jan 2005, Alan Cox wrote:
>
> Alan Cox (the other Alan Cox not me)
Oh no! You guys are multiplying!
Run! Run for your lives!
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Sad, 2005-01-15 at 23:42, [EMAIL PROTECTED] wrote:
> The beauty of Linus's scheme is that direct hardware-to-hardware
> copying is possible, without inventing new kernel interfaces.
You appear to need some simple kernel interfaces but not many and the
low level is there. This looks much cleaner
The beauty of Linus's scheme is that direct hardware-to-hardware
copying is possible, without inventing new kernel interfaces.
Take a step way back to general software design, and consider a
unidirectional communications channel between a data producer and a
data consumer.
The data producer can b
15 matches
Mail list logo
