Hello,
On Monday 18 March 2002 04:12, David Brownell wrote:
> > thus no ioctl().
>
> There's this thing called JNI, which solves that. If they're doing stuff
> like memory mapping the video memory, it's being used already.
> If not, no big deal since the code is Linux-specific in the first place.
Ah, I didn't know that. Unfortunately, not all USB drivers have an /proc/
interface like CPiA.
> That gets to virtues of having a standard "FOO" structure.
> Having a "user friendly" text access to that data would seem
> reasonable to me ... though I still won't expect programs to
> be parsing those text files.
If it's available as "user friendly" text its parsable by scripts...
> Another potential "standard FOO" virtue, yes.
*nod*
>
> > 3) How should this information be presented in textual form in
> > /proc/bus/usb/*?
>
> I thought you were suggesting lines in "devices"?
That, or entries in the subdirectories. "device" would, from a user point
of view, probably make most sense (only one place to look)
> For example,
> each interface that was bound might have a "U:" line, which could
> have "char 180/32" (and if devfs were in use, the name it uses)
Remember there could be multiple U: lines (does anybody know offhand of a
USB device that has multiple physical devices on one USB interface?) As to
the /devfs name... Could be done, but I would like to put the amount of
logic that is needed ina user program to a minimum, so 'old' style /dev
should be listed as well.
> or "net eth2" (ideally with a more fundamental ID too, since as I
> recall those names can be reassigned ... worth looking at what
> ethtool does, as Brad suggested).
Please explain "more fundamental ID" ? "net eth2" sounds fine (or perhaps,
"net:eth2"). It's either something like that or a node starting with a / .
> For character and block devices, the "char 180/32" would be
> the "true" name ... UNIX (and Linux) have a characteristic that
> those names can be bound to other names, but that's not an
> issue that can be changed very easily. (As in your example:
> /dev/video0 and /devfs/v4l/video0 are aliases for char 81/0.)
> Those are the "higher level" names I was referring to.
Mmm. In theory, the names in /dev could be different, but any vendor who is
going to name his devices inodes different from 'the standard' (whatever
that is) is either nuts or out of business very soon :-) /devfs at least
has fixed names.
> Sure. Here's a draft of what "FOO" might be. If it's USB-specific
> it could be in <linux/usbdevice_fs.h>, and that's all I'll suggest for
> the moment.
>
> struct FOO {
> enum { char, block, net } FOO_type;
> union {
> // type "char" or "block"
> struct { int major, minor;} dev;
> // type "net"
> struct { char name [IFNAMSIZ]; } net
> // ... what else
> } u;
> };
It's a start :-) I'll start thinking about it, but I would rather do it
good (or as good as possible) the first time and make it more generic.
>
> That's legal C++ as I recall, but I forget whether ANSI-C allows
> anonymous enums and unions like that ... putting this together
> in usable form is an exercise for someone else! :)
I do recall a similar project/patch that has been posted to this list once;
I'll try to find it and see about its status. I'm volounteering for the job
:-)
- Nemosoft
--
Linux Philips webcam driver page: http://www.smcc.demon.nl/webcam/
Includes FAQs, links to working programs and lots of info.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
