Thanks for your quick reply. Oliver Neukum wrote:
usblp ? sorry I don't get this.Question1: How do I make my device show up automatically in the devfs?
or procfs?
You register with devfs. To do so you need a call like this: usblp->devfs = devfs_register(usb_devfs_handle, name, ... in your probe method.
But this basicly means you have to register the device as if it was just another char device.
No special nothing from usb framework, right?
Yes not really but I thought there might be something more to it since it is part of the usb_driver structure.There doesn't seem to be much documentation on the fops part of the usbIt's not specific to USB. Look at documentation for character devices
drivers. (Maybe I need newer documentation from somewhere?)
to see a description.
I have the book "Linux device drivers 2nd ed" pretty good :-)
Question2: Ok so there is suppose to be 16 devices now. right?Right.
;-)
How do my ftdi_write procedure know which one he is currently working on?There are two ways. Either you extract the minor from the inode which
you can take from struct file* you are passed using minor() and maintain
a table of minors.
Or you do this only on open() and store a pointer to the context in the
private_data field of struct file.
The second way is faster, the first makes it easier to write disconnect()
handlers.
Ok I figured this out in the mean time.
But since there are alot more than 16 usb devices out there.And then how does the fops link to the usb stuff?Convinience and sharing a major number.
I've made a so called "context" in ftdi_probe and passed that back as a
pointer right?
So should I be able to get that from ftdi_write somehow?
Or what it the point of having fops in the usb_driver?
Isn't this looking for trouble?
So there is really no reason not to make the char interface the same way as any other char device driver?
Ok one more question.
There are only 16 devices. But does this limit the driver to 16 physical devices outside the computer?
Or can I handle more than 16 devices.
My idea is to use the seek command te select the device and then read and write to it.
The reason for not using ioctl is that this driver needs to be handled by Kylix :-(
Thanks
-Heinrich
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel