Hi,
Since the [EMAIL PROTECTED] list seems to be rather ill,
I thought I'd forward this to the linux-usb-devel list
(still functional, it seems) and some of the interested
parties.
This is low-impact. USB device drivers without an ioctl method
will politely report ENOSYS; others can now get requests from
userspace to perform tasks. Such calls augment the raw USB I/O
calls that usbdevfs currently provides.
- Dave
----- Original Message -----
From: "David Brownell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, 6 June, 2000 2:51 PM
Subject: PATCH: usbdevfs interface ioctls + hub "list children" request
> Here's the stuff I promised: an API letting a userspace client
> issue ioctls to kernel space drivers. That means you can send
> and receive ioctl-sized (max 16K) chunks of data to drivers for
> any purpose you need, through usbdevfs. Define your own ioctls.
>
> The ioctl provided (see sample "ioctl.c") talks to the hub driver
> and finds out what children the hub has, by USB address. It's
> behaved quite nicely and correctly for me so far. This was one
> of the key remaining bits of usb/devices text that was unavailable
> without writing text parsing code.
>
> This sort of framework should work nicely for the case where a
> user mode driver (maybe some sort of manager) needs to interact
> with a kernel mode driver to control something. Also, such a
> kernel driver might help "safely" issue control messages.
>
> It ought to work for any USB driver that may not have another
> presence on the file system ... hubs, network interfaces, and
> so forth. Against 2.4.0-test1-ac10 (maybe ac8+).
>
> Comments?
>
> - Dave
>
> p.s. there's an #if 0 to remove a warning message, too.
>
>
>
ifioctl.patch
ioctl.c
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
