[linux-dvb] Re: Alternative v4 demux API

[Michael Hunold <hunold@convergence.de>]

Hello Holger,

> > I'd really like to know what stuff is not covered by my approach and 
> > why you think it's too high level.
> It makes abstractions that don't match any hardware I know. I don't know 
> any hardware that has real stream filters in the decoder units.
But some hardware has specialized filters in the demux unit, hence they 
are more bound to the mpeg decoder, that the demux.

And if the hardware uses general purpose PID filters to feed the mpeg 
decoder: no problem either, then you simply name some of these filters 
"special mpeg decoder PID filters".

> It's more the question whether you want to implement raw disk accesses 
> or rather want to use the filesystem layer for your video recordings, not?
Yes. If you don't have to worry about the kernel <=> user barrier then 
these things are easier to solve.

> I have only the 2.4 reference here, maybe this has changed in 2.6. Take 
> a closer look on /usr/src/linux/fs/buffers.c, function 
> generic_direct_IO() and brw_kiovec(). These are the actual 
> implementations of the direct_IO() callback in struct 
> address_space_operations in the file system layer. This function is 
> basically the bridge between inodes in the file systems and IDE/SCSI 
> blocks. Here the mapped kiobufs of the inode get written to disk and new 
> requested buffers get allocated.
>
> The demux driver would have to lock the kiobuf, start the DMA transfer, 
> then mark the page as dirty and flush it.
>
> The good thing about an approach like this would be that you could use 
> any filesystem you like for your video data partition and get things 
> like journalling for free (if you want it and your processor has the 
> headroom to handle it).
Using the generic Linux filesystem is a must IMHO.

Hm, your approach sounds reasonable, I wonder if there is an "offical" 
way to get this inter-subsystem (dvb => fs) done "the right way"(tm).

One thing that I don't understand yet, is how userspace is supposed to 
set up these things, or if it is not involved here. Basically, you have 
two memory regions (one dvb buffer, one fs buffer) which can be 
identical, but have to be shared and synchronized between the two kernel 
subsystems.

Perhaps I should ask this on lkml or the linux-ide mailing list, just in 
case someone has already done this the one way or the other.

> This actually depends on the platform you are talking about, not? 
Yes, sure.

> In any 
> case you want to use accelerating and power-saving hardware on embedded 
> platforms where available, the CPU can probably always do better things 
> than just copying bytes around. 
Yes. But without a good, basically working idea / framework in the 
background, I cannot say if this "memory sharing" stuff is really going 
to work. 8-/

> It's the same as for your harddisk - you 
> don't want to use PIO if DMA is available, right? PIO is nothing else 
> than copying memory byte-by-byte using the CPU to the IDE bus.
I admit that memcpy() is waste of CPU power. But pure memcpy() is way 
faster than PIO access, where you have to poll h/w registers.

Some hardware has specialized memcpy() hardware on-board, perhaps that 
can be used sometimes... ;-)

> Holger
CU
Michael.



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