Hi...
?
I am currently writing a driver for a hardware codec accelerator. ?The calling application will open a media file, write to the codec driver, and read frames back from the codec driver. ?My issue comes with the read of the media file. ?The structure of media files is complex and I'd rather the calling application didn't need to have any knowledge of that structure. ?But how can the driver do the necessary read() operations?
?
I could, for example, have the application pass an open file descriptor in to my driver via an ioctl() call; if I understand matters correctly, my driver could then call sys_read(). ?I've never done anything like that before, never expected to need to, and it doesn't feel right.
?
Can anyone suggest the *proper* way to accomplish this?
?
I am not a member the list list; I hit the weeklies pretty frequently, but I'd appreciate it any responders would CC me directly at [email protected]. ??Thanks.
?
--Van Wanless
EQware Engineering, Inc.
[email protected]
van wrote:
> Hi...
>
> I am currently writing a driver for a hardware codec accelerator. The calling application will open a media file, write to the codec driver, and read frames back from the codec driver. My issue comes with the read of the media file. The structure of media files is complex and I'd rather the calling application didn't need to have any knowledge of that structure. But how can the driver do the necessary read() operations?
>
> I could, for example, have the application pass an open file descriptor in to my driver via an ioctl() call; if I understand matters correctly, my driver could then call sys_read(). I've never done anything like that before, never expected to need to, and it doesn't feel right.
>
> Can anyone suggest the *proper* way to accomplish this?
>
> I am not a member the list list; I hit the weeklies pretty frequently, but I'd appreciate it any responders would CC me directly at [email protected]. Thanks.
>
The best way is to mmap() the file into memory, then pass the address to
the driver.
--
Brian Gerst
On Wed, May 25, 2005 at 01:41:43AM -0400, Brian Gerst wrote:
> van wrote:
> >the media file. The structure of media files is complex and I'd rather
> >the calling application didn't need to have any knowledge of that
> >structure. But how can the driver do the necessary read() operations?
> The best way is to mmap() the file into memory, then pass the address to
> the driver.
That probably is a good way. An alternative might be for the driver
to pass some paramaterized knowledge of the file structure back to
the userland app. That would prevent the userland app from having
to know as much a priori, but it may be difficult to figure-out how
to describe the media files' structure in a paramaterized way.
YMMV... :-)
John
--
John W. Linville
[email protected]
On Middeweken 25 Mai 2005 07:15, van wrote:
> ?The structure of media files is complex and I'd rather the calling application
> ?didn't need to have any knowledge of that structure. ?But how can the driver
> ?do the necessary read() operations?
> ?
> I could, for example, have the application pass an open file descriptor in to
> my driver via an ioctl() call; if I understand matters correctly, my driver
> could then call sys_read(). ?I've never done anything like that before, never
> expected to need to, and it doesn't feel right.
_if_ you want to read the file, use fget() and vfs_read() on the file
descriptor you get passed. It is however considered rather bad style to
do file I/O from drivers. As Brian Gerst said, better use mmap in user
space and pass the pointer via ioctl() or write().
> Can anyone suggest the *proper* way to accomplish this?
Your assumption that the driver should parse the media file structure
is probably wrong. You should rather do as much as possible in a user
space library. Pass a file name to a library call and have that
work with all the complex parts of the file format, then define an
ioctl interface for the driver on a relatively low level.
Or even better, don't use ioctl() at all but implement only read()/write()
in the driver. E.g. for MPEG acceleration, you might want to have an
interface where you write a series of macro blocks to the character
device and read back pixel data.
Arnd <><