Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 May 2011 17:12:41 -0500
From:      Jim Bryant <kc5vdj.freebsd@gmail.com>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        freebsd-drivers@freebsd.org, freebsd-usb@freebsd.org
Subject:   Re: traditional syscalls with DRIVER_MODULE ????
Message-ID:  <4DDD7ED9.90500@gmail.com>
In-Reply-To: <201105252133.23321.hselasky@c2i.net>
References:  <4DDC20DF.6060805@gmail.com> <201105242324.15541.hselasky@c2i.net> <4DDD5245.3040500@gmail.com> <201105252133.23321.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
excuse me while i pull my head out of my posterior...

yup.

it wasn't DRIVER_MODULE() doing it...  it was the usb_fifo_attach....

i think i'm back on the right track now...  thanks for pointing me in 
the right direction.


Hans Petter Selasky wrote:
> Hi,
>
> On Wednesday 25 May 2011 21:02:29 Jim Bryant wrote:
>   
>> do start_read/stop_read and start_write/stop_write map directly to the
>> userland read(2) and write(2) calls?
>>     
>
> No, but they are called from these calls. The idea is that you use the FIFO 
> mechanism already present there when moving data, and poll() will be 
> automatically handled. Probably that is not suitable for your purpose?
>
>   
>> i had looked at this previously, and am a bit confused on if the above
>> is correct.
>>
>> even if they are the direct interface to read(2)/write(2), the issue of
>> a poll method for select(2) still exists...
>>
>> grepping all DRIVER_MODULE usages comes up with only two poll methods:
>>
>> powerpc/powermac/pmu.c:        DEVMETHOD(adb_hb_controller_poll,
>> pmu_poll),
>> powerpc/powermac/cuda.c:       DEVMETHOD(adb_hb_controller_poll,
>> cuda_poll),
>>
>> and those are unhelpful.
>>
>>     
>
>   
>> please excuse me if these are newbie questions, but, i'm still in the
>> learning process.
>>     
>
> It is OK to ask questions :-)
>
>   
>> i can do this if there is a way to prevent DRIVER_MODULE from creating
>> the devfs nodes, and instead do this in a hybrid way using DRIVER_MODULE
>> and make_dev(9), which has the exact traditional functionality i want in
>> this.  any ideas?
>>     
>
> Why can't you create the node when you receive a device_attach event?
>
>   
>> two of the three device nodes this driver will create
>> will require read(2)/select(2) interfaces visible to userland, and the
>> third driver will require write(2) visible to userland.
>>     
>
>   
>> the question is: is there a way to use DRIVER_MODULE, which seems
>> necessary for usbdi, yet create the devfs nodes using make_dev/cdevsw?
>> i would prefer to not have DRIVER_MODULE create the device nodes.
>>     
>
> DRIVER_MODULE() only will create devices if you have a load function which 
> does so. It is only called once!
>
> --HPS
>
>   




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DDD7ED9.90500>