On Thu, May 04, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
> > I'd also like to add a number 5:
> >
> > 5. Standardize on one UHCI driver
>
> Not surprised to see this added. It was almost in my
> list. I agree that we need to decide on this
> issue, but it's not a burning priority like PnP is
> (except maybe to you, since it involves you & your time).
For a couple of reasons. If people don't want to use my driver, there's
very little reason to continue putting work into it. The same goes for
the AFS driver I would assume. Plus, trying to support 2 drivers on the
list when lots of people start using USB will be more trouble than it's
worth.
> > > c. Remove some of the backwards-compatibility API.
> >
> > Which backwards-compatible API are you talking about? I'd like to keep
> > usb_control_msg and usb_bulk_msg, but nuke usb_request_irq,
> > usb_request_bulk and usb_terminate_bulk.
> >
> > According to my sources, the only driver which uses usb_request_irq is
> > uss720.c and it doesn't seem all too difficult to fix.
> >
> > usb_control_msg and usb_bulk_msg are more convenience functions to do
> > synchronous transfers than backward compatible API's.
>
> Same conclusion, similar reasoning.
> So do we need to leave the "nuke" ones for awhile, marked as
> Deprecated, or nuke them now to discourage their use (if there
> are some non-Linux-kernel-source code drivers using them)?
> (and get uss720.c changed)
It could go either way. Remove them now before 2.4 gets released and find
the broken drivers now, or have to support them all of the way through 2.4.
Granted, the likely hood of something changing so that we have to revisit
the compatibility API's to fix them is unlikely.
> > > Request from Martin Mares:
> > > - I'd also like to see some support for progress reporting
> > > on bulk URB's. It's needed for my USB networking
> > > driver which is close to being finished and I'd like to see
> > > it in one of the first few 2.4 releases.
> >
> > Should we create a new API call for this?
> >
> > usb_status_urb which forces the HC driver to check on the status and
> > update lengths, status, etc?
>
> We really haven't discussed this functionality.
> I put it here because MM responded to the last USB jobs list
> with this request. How important is it? Is it something
> that several drivers would like/would use?
>
> It seems a little "different" to me. You don't ask
> PCI or SCSI or an Ethernet adapter or a modem how much of a
> transfer it has completed, do you? You could, but I don't
> think that they are mainstream requests.
>
> Or asked another way: What does this provide to a driver?
> A chance to increase performance by being able to stream
> some I/O requests a little better? If so, that would be
> interesting to me.
I don't see the performance reasons for it, but apparentely Martin requires
it ("needed for my USB networking driver").
Martin, what are trying to do with the information?
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
