Hi, David!
On Fri, 2005-11-04 at 11:07 +1100, David Gibson wrote:
> > Actual reason might be that usb_kill_urb() waits until it's done and for
> > some reason urb never gets done. usb_unlink_urb() on the other hand is
> > asynchronous and returns immediately. It also might be that I made some
> > other errors while testing which resulted in hangup but since everything
> > was working fine with that usb_unlink_urb() in ezusb_request_timerfn() I
> > felt there was no need for further experiments.
>
> Yeah.. making random changes 'cos they seem to make it stop crashing
> without a clear mental model of why it's correct really isn't a great
> way to program. Unfortunately, of course, the orinco_usb driver is
> already full of crap like this, which is exactly why it hasn't been
> merged.
I can understand if the function is essentially renamed just to simplify
things or to take different arguments, but usb_kill_urb() vs
usb_unlink_urb() seems to be trickier.
> > I would like to see orinoco-usb getting into main kernel someday and I
> > could do some coding to make that happen but with no linux kernel
> > programming experience it's rather hard to know what to do.
>
> It's my opinion that the orinoco_usb driver needs some fairly
> fundamental restructuring in order to me mergable. At the moment it's
> a hack on top of the general orinoco driver, and it's not a good fit.
> THe differences with the USB device are sufficient that I think it
> really needs to be a more separate driver - sharing substantial
> library routines with other orinoco devices, but having an essentially
> separate Rx and Tx path.
Maybe the separation of code between hermes.c and orinoco.c should be
adjusted so that orinoco.c is such library, whereas hermes.c has
everything the USB code doesn't need, including Tx and Rx. Of course,
the files don't need to be called hermes.c and orinoco.c - I think
hermes.c could be renamed to orinoco-hw.c or something like that.
Please don't forget that we may want to support Prism based USB devices,
which would need another low-level implementation but the same mapping
between RIDs and wireless extensions.
I'm pretty much ready to release 0.15, the only possible remaining issue
being suspend/resume in orinoco_plx. Getting the code into the kernel
is not such an issue, since most code is in the kernel already, and I'm
sure the remaining pieces will be accepted.
Once done with the release, I'm open to massive changes, but I'm not
sure the USB issue will get priority.
I have a gut feeling that orinoco_usb is over-engineered, since I don't
see state machines in other network USB drivers. And we'll need some
way to match the locking schemes of USB and non-USB drivers to reuse the
common code safely.
--
Regards,
Pavel Roskin
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
|
