[ECOS] device driver interface

[ECOS] device driver interface

[Koeller, T.]

Hi all,

what would be the recommended way of coding a device driver that does
not fit the rather rudimentary and rigid read/write/set_config/get_config
model
as described by the documentation? If, for example, I wanted asynchronous
notifications upon certain driver-detected events, such as data arriving, is
there a standard way of coding this, or do I have to use sychronization
primitives directly, extending the I/O API in a nonstandard way? Is there
something similar to an ioctl API, allowing for more generalized I/O
operations
that require additional parameters beyond just a buffer and a byte count?
Can I attach context information to I/O requests that can be retrieved
after the operation is finished?

Any advice greatly appreciated!

Thomas
----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com 
http://www.baslerweb.com 


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] device driver interface

[Jonathan Larmour]

"Koeller, T." wrote:
> 
> Hi all,
> 
> what would be the recommended way of coding a device driver that does
> not fit the rather rudimentary and rigid read/write/set_config/get_config
> model
> as described by the documentation? If, for example, I wanted asynchronous
> notifications upon certain driver-detected events, such as data arriving, is
> there a standard way of coding this, or do I have to use sychronization
> primitives directly, extending the I/O API in a nonstandard way? Is there
> something similar to an ioctl API, allowing for more generalized I/O
> operations
> that require additional parameters beyond just a buffer and a byte count?

That's indeed something which set_config/get_config could theoretically do.

> Can I attach context information to I/O requests that can be retrieved
> after the operation is finished?

Not easily.

Remember the cyg_io_* functions are only there to provide a framework. If
your device isn't really able to support it, then just go ahead and provide
your own io/whatever package with its own API in a header file. If your
application has to have detailed knowledge about the driver it is using,
there's little point forcing the interface to be the "generic" API.

There's no point fitting a round peg in a square hole :-).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss