File I/O from within a driver

File I/O from within a driver

[van]

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 van.wanless@eqware.net.   Thanks.
 
--Van Wanless
EQware Engineering, Inc.
van.wanless@eqware.net

Re: File I/O from within a driver

[Brian Gerst]

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 van.wanless@eqware.net.   Thanks.
>

The best way is to mmap() the file into memory, then pass the address to 
the driver.

--
				Brian Gerst

Re: File I/O from within a driver

[John W. Linville]

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
linville@tuxdriver.com

Re: File I/O from within a driver

[Arnd Bergmann]

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 <><