excuse me while i pull my head out of my posterior...
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:
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
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.
please excuse me if these are newbie questions, but, i'm still in the
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!
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"