[no subject]

I'd like to watch the debug messages for the ugen driver, but I'm having
trouble getting the debug messages to go. I put 'options UGEN_DEBUG' in my
kernel conf file and I recompiled and installed, but when I do a 'nm
/modules/ugen.ko | grep ugendebug' that symbol isn't defined and if I try to
do an ioctl(USB_SETDEBUG) I get an 'Invalid Argument' error. It turns out
that if I do 'nm ugen.o | grep ugendebug' in my kernel compile directory it
prints out the symbol, but the kernel module doesn't seem to be getting the
option. In fact if I look at opt_usb.h in my kernel compile directory I see
'#define UGEN_DEBUG 1', but if I look at
'modules/usr/src/sys/modules/ugen/opt_usb.h' under my kernel compile
directory, it is blank.

>I had been thinking of adding another mode to ugen where there is a queue
>of read/write transactions and you can use select() to pace the creation
>of new transactions - as you do with a socket or a tty style device.  This
>would be quite easy to add to ugen to suit my requirements (maintaining a
>smooth stream of smallish (~1Kbyte) transactions in both directions), but
>enhancing it to solve your problem of wanting to break a huge transaction
>into small pieces (and presumably to start processing those pieces before
>the transaction is complete) would be more tricky.

Ahh. I'm beginning to understand why he did it. His scenario would go
something like this:

- write a request to the palm for a list of databases
- read the packet header returned from the palm: read(6)
- from the packet header, get the length and read that: read(123)

I think the problem he was trying to combat was that he thought that the
following could happen:
- write a request to the palm for a list of databases
- read the packet header returned from the palm: read(6)
- the ugen driver reads a 129 byte transaction from the USB bus and returns
6 bytes, but deletes the other 123 bytes because it doesn't buffer between
reads.
- from the packet header, get the length and read that: read(123), but this
read would then fail because the rest of that data was wiped after the
previous read

Is that possible? If it is, I think that it is working without his buffering
because the header is sent in a separate transaction from the payload. So
when he does that read(6) it is just grabbing the header transaction and
the next 123 bytes comes in the next transaction.
(These headers and payloads are a protocol on top of USB, not the USB
protocol headers and payloads).




To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-hardware" in the body of the message