Re: Make pipe data structure be a circular list of pages, rather

[Ingo Oeser]

Hi Linus,

Linus Torvalds wrote:
> On Thu, 13 Jan 2005, Ingo Oeser wrote:
> > Hmm, that's a pity, because it makes hardware support more difficult.
> > I thought you might consider an system call, which "wires up" fds.
> I think that the solution to that is to make the pipe _be_ the driver
> interface.

But we have currently no suitable interface for this.

We have socketpair(), we have pipe(), but we don't have
dev_pipe() creating a pipe with the driver sitting in the middle.

Usage: "processing devices" like crypto processors, DSPs, 
 MPEG-Encoding/-Decoding hardware, smart cards and the like.

Synopsys: int dev_pipe(const char *dev_path, int fd_vec[2]);

We also don't have wire_fds(), which would wire up two fds by 
connecting the underlying file pointers with each other and closing the fds.

That would be quite useful, because user space will not see the data anymore
anyway, if it travels just between some chips. 

Usage: Chips from a chipset, which usally know each other quite well and
 can talk to each other without CPU intervention.

Synopsys: int wire(int in_fd, int out_fd);

> But that doesn't make the pipe an "actor". The pipe just remains a
> standard way to encapsulate the notion of "set of buffers". It needs an
> external actor to do something, but that actor can be a device driver
> filling it up, or a system call that reads it or moves it to another
> destination.

I implemented this some years ago for the "Linux & DSP" project, 
but I had to impose ordering restrictions on open() and close() to user space
and this is not really elegant.

Many hardware vendors have implemented it somehow anyway.

So what about starting to do it seriously and implement infrastructure for 
both of it?

I could also do an simple example driver using both features, if you give me 
some evenings of time and are interested in the idea.

Are you interested?


Regards

Ingo Oeser, still dreaming of sys_wire() and sys_dev_pipe()

PS: Syscall names are under discussion of course ;-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/