traditional syscalls with DRIVER_MODULE ????

Jim Bryant kc5vdj.freebsd at gmail.com
Wed May 25 19:03:11 UTC 2011


do start_read/stop_read and start_write/stop_write map directly to the 
userland read(2) and write(2) calls?

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.

usb_fifo_methods doesn't seem to have a poll, how would i go about 
this?  select(2) is a more familiar interface for application 
programmers to use for this purpose, instead of using an ioctl for the 
same functionality in a way that is not compatible with select(2).

please excuse me if these are newbie questions, but, i'm still in the 
learning process.

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

am i missing something?  i again apologize for the newbie questions...

jim

Hans Petter Selasky wrote:
> On Tuesday 24 May 2011 23:19:27 Jim Bryant wrote:
>   
>> if i add such an interface to the current DRIVER_MODULE version, how 
>> would i go about NOT having DRIVER_MODULE create the devfs entries?  i 
>> would prefer to have the devfs entries handled by make_dev, so to have 
>> access to the desired syscalls.
>>     
>
> Look at /sys/dev/usb/serial/ulpt.c
>
> For a simple example.
>
> More abstract:
>
> "cd /usr/ports/multimedia/cuse4bsd" and "man libusb20"
>
> --HPS
>
>   


More information about the freebsd-usb mailing list