[linux-dvb] Re: Alternative v4 demux API

[Michael Hunold <hunold@convergence.de>]

Hello Holger,

> I like the idea of a source based routing in Michael's approach (we've 
> been discussing this issue before in another thread some months ago), 
> the idea not to specify input and output device of the demux but instead 
> specify a stream source in the decoder. This removes some ambingiuties.
Yes.

> If we want to remove even more ambinguities we should distinguish in the 
> demux API between general purpose filter banks and decoder-attached 
> filter banks.
Yes, or separate this to separate devices. The latter has the advantage, 
that adding specialized IOCTLs for example is really bound to a special 
device.

If you have the mpeg demux, for example, adding a (if it makes sense or 
not) "MPEG_DEMUX_FAULT_TOLERANT" IOCTL is easy and is bound to that 
device, it's not available for the general purpose PID filters.

> But the remaining ideas of Michael's approach don't map the current 
> hardware enough and are too specialized and high-level, so think it's 
> better to stick to the dedicated flexible demux device which does both 
> packet demultiplexing and routing.
I'd really like to know what stuff is not covered by my approach and why 
you think it's too high level.

As I already have written in my latest answer to Ralph, putting the 
recording stuff and the special teletext filter into the general purpose 
PID filter is ok for me.

But hey, these are 2 special devices. Currently I don't see that more 
special devices are coming. And as I already said: legacy applications 
does not neet to be changed, they can use general PID filters as before. 
But if the special devices exists, they can use them with no extra cost.

But I stick to separating the mpeg demux/filters / PID filters / section 
filters to separate devices.

> > You will not find a perfect combination of devices which will fit all
> > hardware.  The question is what is the best compromise.
> > If you make the device API too simple the drivers will have to do a
> > lot of patchworking (e.g. automatically using recording units instead
> > of normal filters when possible/necessary). If the API supports too
> > many special devices the user application will have to do a lot of 
> > checking (what devices are there, how can I use them, etc.)
>
> Can you please specify the term 'special recording unit' a little more 
> in detail? -- Are you simply talking about hardware that does just DMA's 
> a demuxed stream into a dedicated memory area and allows simultanous DMA 
> transfers from this area to the harddisk?
For example. Or the hardware automatically sets up IDE DMA transfers if 
told so. I admit that this does not make sense for systems like Linux, 
where you usally don't write to any drive outside of the ide layer.

But if you really like to do that, having a separate recording device is 
handy: as described above, you can add whatever IOCTLs you like, even if 
your device driver, not just in the dvb-core.

This is way more complicated if you do this through the one-in-all demux 
approach.

> Would it not be sufficient to add a output route into a file descriptor 
> so that the kiobufs of the filesystem layers can get feeded using the 
> demux DMA pointers directly (don't know whether 2.6 still uses kiobufs, 
> maybe this has changed, but the underlying concepts are probably the same).
It's indeed a problem that for a recording, all data is copied from DVB 
to user space, just to be pushed to the IDE layer afterwards. But this 
is a Linux problem in general.

> Or even simpler: Make the demux output ringbuffer double-buffered and
> allow to relocate the backbuffer from userspace using a demux-ioctl. A
> userspace program would now mmap() the destination file, then relocate
> the backbuffer. As soon front- and backbuffers get flipped the demux
>  API
> faults this page in and then DMA's into this area. Maybe one needs
> more
> than 2 buffers, maybe a quad-buffered architecture is required to get
> fluent transfers.

In theory, you can write to user space memory from device drivers 
easily. In practise, most hardware has some sort of DMA limitations (for 
example 16k aligned memory), so this is not an option unfortunately, 
because you cannot control memory allocation for userspace.

As you pointed out, another approach is to let the user application 
mmap() the kernel dvb ringbuffer.

But I don't know if this works well with the Linux IDE / SCSI layer, 
though, ie. if these layers can handle the mmap()ed pointers afterwards.

But before thinking about this, someone should really investigate if 
these memcpy()s are *really* a problem for system performance. Sure, 
there is a lot of copying going on, but I guess that most of the *real* 
performance is eaten somewhere else.

> > Regarding the special PID and section filter devices I do not see a
> > real difference compared to having them all in the demux device besides
> > inflating the number of devices.
> Has the approach of using a single dvb device per adapter been ever 
> discussed? This would require adding a device id to every control 
> struct, don't know whether this is a good idea...
Another drawback would be that you couldn't use standard Linux / unit 
filehandling stuff like read(), write(), poll()/select() and so one. You 
would need to simulate this stuff with ioctls, then.

This isn't a major problem, though IMHO. For a read() "ioctl" you'd 
simply need a separate struct like this:

struct dvb_read {
	int "filehandle";
	char *mem;
	ssize_t len;
}

> Holger
CU
Michael.



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.