This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Re: Driver questions


The rationale for my query is based on a desire to implement a
OSS (open sound system) compliant sound driver. I.e., <sys/soundcard.h>
type interface as exists in Linux. 

The semantics of the OSS driver requires the facilities I mentioned 
below. e.g., only one "open" at a time, IOCTLs for device configuration,
etc. The obvious benefit to following the OSS standard is to reduce
porting time for Linux/OSS audio applications.

Thanks,
/Jim


>Jonathan Larmour <jlarmour@redhat.com> wrote:
>
>jyl087@netscape.net wrote:
>> 
>> Hello,
>> 
>> I'm trying to implement a new device driver, and am using the serial driver
>> as a template. I've read through the source files for serial, and have a
>> few questions:
>> 
>> 1. The device filesystem (devfs.cxx) seems to throw away ioctl calls.
>>    Why was it decided to do this?  dev_fo_setinfo seems to provide a
>>    similar capability, but isn't standard.  Should dev_fo_ioctl be modified
>>    to point to dev_fo_setinfo?
>
>Doesn't sound unreasonable. But it does sort of beg the question: why not
>just use the cyg_io interface directly anyway? What's the advantage of
>using a "standard" interface, given all the arguments to it are
>non-standard anyway? 
>
>> 2. dev_fo_close is similarly thrown away, rather than vectored through a
>>    DEVIO function. Should this be changed? For my device, I'd like to
>>    return an error if the user tries to open it multiple times. I was
>>    thinking of using close to record a state var indicating that the
>>    first user had successfully relinquished the driver.
>
>There isn't a cyg_io_close() function. The model isn't really intended for
>that as such - just like cyg_io_lookup() isn't really the same as an open.
>
>And in general, there's no reason why, at this level, we should be
>restricting devices to one open or close, particularly since there are only
>handles to devices as a whole, not user instances.
> 
>> 3. dev_fo_open - Looks like the mode variable isn't passed down to the
>>    device "lookup" function. My device needs to know if "O_RDONLY" or
>>    "O_WRONLY" is being requested...
>
>I suppose we could add new config keys to indicate this and do a
>cyg_io_setconfig on the device to set that after the open (ignoring any
>error indicating the key is unknown by the driver, rather than read/write
>itself not being permitted. Got a patch? :-)
>
>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
>
>


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]