archive mirror
 help / color / mirror / Atom feed
From: Ingo Oeser <>
To: Linus Torvalds <>
Cc:, Kernel Mailing List <>
Subject: Re: Make pipe data structure be a circular list of pages, rather
Date: Mon, 17 Jan 2005 17:03:58 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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, size_t len, unsigned long flags) 
> +asmlinkage long sys_splice(int fdin, int fdout, size_t len, unsigned long flags) 

That part looks quite perfect. As long as they stay like this, I'm totally 
happy. I have even no problem about limiting to a length, since I can use that
to measure progress (e.g. a simple progress bar). 

This way I also keep the process as an "actor" like "" pointed out.

It has unnecessary scheduling overhead, but the ability to stop/resume
the transfer by killing the process doing it is worth it, I agree.

So I would put a structure in the inode identifying the special device
and check, whether the "in" and "out" parameters are from devices suitable
for a direct on wire transfer. If they are, I just set up some registers
and wait for the transfer to happen. 

Then I get an interrupt/wakeup, if the requested amount is streamed, increment some 
user space pointers, switch to user space, user space tells me abort or stream
more and I follow. 
Continue until abort by user or streaming problems happen.

Just to give you an idea: I debugged such a machine and I had a hard hanging 
kernel with interrupts disabled. It still got data from a tuner, through an
MPEG decoder, an MPEG demultiplexer and played it to the audio card.
Not just a buffer like ALSA/OSS, but as long as I would like and it's end to end
without any CPU intervention.

That behavior would be perfect, but I could also live with a "pushing process".


Ingo Oeser

  reply	other threads:[~2005-01-17 16:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-08  8:25 Make pipe data structure be a circular list of pages, rather linux
2005-01-08 18:41 ` Linus Torvalds
2005-01-08 21:47   ` Alan Cox
2005-01-13 21:46   ` Ingo Oeser
2005-01-13 22:32     ` Linus Torvalds
2005-01-14 21:03       ` Ingo Oeser
2005-01-14 21:29         ` Linus Torvalds
2005-01-14 22:12           ` Ingo Oeser
2005-01-14 22:44             ` Linus Torvalds
2005-01-14 23:34               ` Ingo Oeser
2005-01-15  0:16                 ` Linus Torvalds
2005-01-16  2:59                   ` Linus Torvalds
2005-01-17 16:03                     ` Ingo Oeser [this message]
2005-01-19 21:12                     ` Make pipe data structure be a circular list of pages, rather than linux
2005-01-20  2:06                       ` Robert White
2005-01-15 23:42 Make pipe data structure be a circular list of pages, rather linux
2005-01-15 22:55 ` Alan Cox
2005-01-16  0:12   ` Linus Torvalds
2005-01-16  2:02     ` Miquel van Smoorenburg
2005-01-16  2:06     ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).