Hi Tim,
On 2012-07-02, at 4:14 PM, Tim Roberts wrote:
> Kevyn-Alexandre Paré wrote:
>>
>>>
>>> If timerfd is available on your system, to manage timer expirations
>>> through a file descriptor, that's added to the POLLIN list.
>> thx, The linux kernel that I'm using have timerfd enable!
>>
>> One question remains, how to distinguish the files descriptor from each
>> other?
>
> Why would you need to?
Good question:
The event loop is working that way:
1- register file descriptor (FD) and specify the flag (read or/and write) to be
notified about it.
2- Callback function is called with FD and flag type.
3- In the callback I need to know what the FD is referring to and take action,
ex: data is ready to be read for the FD of bulk transfer.
Since I'm receiving 3 FD I don't know what they are, except there type (POLLIN,
POLLOUT).
More clear?
Here my summary/understanding on the subject:
Summarizing execution order:
0- libusb_init(NULL) // Called from my code.
// libusb LOG:
1- [libusb_init]
2- [usbi_add_pollfd] add fd 7 events 1
(Adding control pipe to read into fds[0])
3- [usbi_io_init] using timerfd for timeouts
4- [usbi_add_pollfd] add fd 9 events 1
(Adding timerfd into fds[1])
5- libusb_open_device_with_vid_pid(NULL, VendorID, ProductID) // Called from my
code.
// libusb LOG
[libusb_get_device_list]
[sysfs_scan_device] scan usb1
[sysfs_scan_device] bus=1 dev=1
[enumerate_device] busnum 1 devaddr 1 session_id 257
[enumerate_device] allocating new device for 1/1 (session 257)
[sysfs_scan_device] scan 1-2
[sysfs_scan_device] bus=1 dev=2
[enumerate_device] busnum 1 devaddr 2 session_id 258
[enumerate_device] allocating new device for 1/2 (session 258)
[libusb_get_device_descriptor]
[libusb_get_device_descriptor]
[libusb_open] open 1.2
[op_open] opening /dev/bus/usb/001/002
[usbi_add_pollfd] add fd 10 events 4
...
[handle_events] poll() 3 fds with timeout in 60000ms
This clearly describe that there is 3 file descriptor that have been add with
usbi_add_pollfd().
This is why the libusb_get_pollfds() will return 3 files descriptor.
Going deeper in the code we clearly see that libusb_init add the 2 first file
descriptor:
1- libusb_init() // From my code to core.c
2- usbi_io_init() // io.c
3- usbi_add_pollfd(ctx, ctx->ctrl_pipe[0], POLLIN) // io.c ADDING THE
CONTROL PIPE
4- usbi_add_pollfd(ctx, ctx->timerfd, POLLIN) // io.c ADDING THE
TIMERFD only on linux see define
5- libusb_open_device_with_vid_pid() // from my code to core.c
6- libusb_open() // core.c
7- op_open() // os/linux_usbfs.c
8- usbi_add_pollfd(HANDLE_CTX(handle), hpriv->fd, POLLOUT) // io.c ADDING
THE DEVICE
>From the initialization we see that the first file descriptor in the list will
>be the control pipe,
second one will be the timerfd and the third one is the device.
The handle_events() comment about the fact that the first 2 have a constant
index:
/* fd[0] is always the ctrl pipe */
/* on timerfd configurations, fds[1] is the timerfd */ // if
USBI_TIMERFD_AVAILABLE
The hack we found to detect if it's a timerfd, when using libusb_get_pollfds(),
is by using:
int result = timerfd_gettime((*iterator)->fd, &localTimerSpec);
if (result < 0)
{
// Not a timerfd
}
A A Proposition could be that libusb support nice API to distinguish them??:
A- Update the struct libusb_pollfd?:
struct libusb_pollfd
{
int fd;
short event;
enum libusb_fd_type type;
};
enum libusb_fd_type
{
LIBUSB_TYPE_UNKNOWN,
LIBUSB_TYPE_CONTROL_PIPE,
LIBUSB_TYPE_TIMERFD,
LIBUSB_TYPE_DEVICE,
};
B- We could add get type function or gettimertype??
libusb_fd_type libusb_get_typefd(int fd)
{
enum libusb_fd_type type = LIBUSB_TYPE_UNKNOWN;
if (fd == fds[0])
type = LIBUSB_TYPE_CONTROL_PIPE;
else if (fd == fds[1])
type = LIBUSB_TYPE_TIMERFD;
else if (fd == fds[2])
type = LIBUSB_TYPE_DEVICE;
return type;
}
Maybe there is better/easier way that I don't see… Otherwise I will please to
push a tested patch.
thx,
- Kevyn-Alexandre
>
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
