traditional syscalls with DRIVER_MODULE ????
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
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:
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
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...
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"
More information about the freebsd-drivers