On Tue, Jan 22, 2008 at 07:52:57PM +0000, Christian Schoenebeck wrote:
> Am Dienstag, 22. Januar 2008 16:26:01 schrieben Sie:
> > Um, I don't think you have explained the problem fully here.
> >
> > If you want to just create a random char device in the kernel, use the
> > misc interface. It's infrastructure will automatically do the proper
> > stuff so that udev will create a /dev node.
> >
> > Otherwise, if you are using your own major number, you will have to set
> > up the needed class information properly so that udev knows how to
> > create your nodes for you. But odds are you really don't need your own
> > special major number, right?
>
> This is the 1st Linux driver I'm writing from scratch, so my main problem I
> admit is that I'm not used to the whole Linux driver framework yet. I
> actually used your book Greg ("where the kernel meets the hardware", 3rd
> edition) to ease this learn process a bit and it was a great help so far!
>
> BTW, I think there is a double-free bug in the book's USB
> example "usb-skeleton.c", function skel_write():
> ...
> error:
> 1-> usb_buffer_free(dev->udev, count, buf, urb->transfer_dma);
> usb_free_urb(urb);
> 2-> kfree(buf);
Heh, good catch :)
> Am Dienstag, 22. Januar 2008 16:27:33 schrieben Sie:
> > Hm, exactly how the usbfs2 endpoints are exported, right? :)
>
> I guess so, because what I'm trying to do is merely just to expose some of
> the
> device's (interrupt) endpoints as separate character device files under /dev.
> The "real" communication is thus moved to a user space app / lib which
> handles the control of the device with simple read() and write() calls to the
> various characters device files. Works fine so for one endpoint, but as said,
> due to the limitation of struct usb_interface (being limited to just one
> minor per USB interface), I could not simply add another usb_register_dev()
> call to create further character devices for the other endpoints of same USB
> interface.
Then why not just use usbfs/libusb directly? That sounds like it would
work for you, and no kernel driver is needed at all.
> If I'd provide a patch, replacing the scalar member of struct usb_interface
>
> by a list of minors instead, would that a have a chance to be applied to the
> upstream kernel? Or is there probably a good reason for keeping it a scalar?
Yes, we need to keep it on a per-interface level because that is what
drivers bind to, not individual endpoints, or endpoint pairs.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
