Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 May 2005 22:52:19 +0200
From:      Dirk GOUDERS <gouders@et.bocholt.fh-ge.de>
To:        freebsd-usb@freebsd.org
Subject:   Re: poll(2)ing or select(2)ing /dev/usb0 
Message-ID:  <200505242052.j4OKqJiI001602@karga.hank.home>
In-Reply-To: Message from Hans Petter Selasky <hselasky@c2i.net> of "Tue, 24 May 2005 21:22:52 %2B0200." <200505242122.53801.hselasky@c2i.net> 

next in thread | previous in thread | raw e-mail | index | archive | help

 > You cannot read data from /dev/usbN, only ioctls are possible on those 
 > devices.
 > 
 > See "/sys/dev/usb/usb.c" (usbpoll), if you got the source code installed.

Ah yes, thank you, now I understand why my programs behave like they do.

To me, it looks as if the manual page usb(4) is a little bit misleading:

<excerpt>
USB CONTROLLER INTERFACE
     Use the following to get access to the USB specific structures and
     defines.

     The /dev/usbN can be opened and a few operations can be performed on it.
     The poll(2) system call will say that I/O is possible on the controller
     device when a USB device has been connected or disconnected to the bus.

     The following ioctl(2) commands are supported on the controller device:
</excerpt>

I understood the text in the following way:

"If you want to know if a device has been connected/disconnected, then
 call poll(2) on /dev/usbN and if poll(2) says that descriptors are
 ready, perform one of the ioctl(2) command to find out what exactly
 happened."


Well, do I understand it right, that the only way to use poll(2) to
come to know if a device has been connected/disconnected to/from the
bus is to poll(2) /dev/usb (the event interface)?  And therefore on a
machine that runs usbd(8), no other process can use poll(2), to come to
know about such events, but has to do it somehow else?

Dirk



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