Re: Perhaps 'myopic' is a better word...

On Sun, Dec 19, 2004, Paul Klissner <Paul.Klissner <at> Sun.COM> wrote:
> I sent email out early this morning claiming libusb 0.8 is fundamentally
> broken. I should scale back that assertion in retrospect, as I think I
> now more fully understand the assumptions under which the 0.8 prototype
> was created.
> 
> Perhaps it is not fair to call libusb 0.8 "broken" for not abstracting
> internal library data away from the client view.  But libusb 0.8 
> significatnly
> constrains it's adaptation to diverse environments by failing to do so.
> Portability is ultimately libusb's biggest appeal to a significant
> percentage of USB application developers with the goal to have our code
> run unchanged on the largest possible number of platforms.
> 
> In libusb 0.8, the assumption seems to be that the library's internal
> view of bus topology (ie. data structures) can only be updated
> synchronously, that is, when the client calls usb_find_busses() and
> usb_find_devices().  With that model locking semantics around
> shared state isn't critical, as all database updates are client driven.
> 
> Such a scheme may be well suited to Linux, but for other platforms,
> the restriction that libusb's database changes are initiated by
> the libusb's client is far from ideal if libusb itself is a client that
> receives hotplug events from its the backend provider, or if the
> client is a multithreaded application wherein multiple threads are
> calling usb_find_*().
> 
> If we provide more abstraction in the API, these issues become moot,
> and can be dealt with by the library through locking. That really
> seems to be the way to go if libusb is to become the Open Source
> standard for multiplatform USB access.

Sorry for the delay in responding. Now that I'm back from vacation, I'm
making my way through old emails.

You're right that this is a poor design choice originally, but I don't
think there's much we can do with 0.1 right now (there is no 0.8, so I
think you mean 0.1.8).

You could internally buffer these bus and device changes until the
application calls the appropriate functions to rescan, for 0.1 atleast.

However, I'd like to fix this in a more intelligent way for 1.0, just
like you do.

It sounds like on your Sun implemention, you receive notifications
about bus and device changes asynchronously, right?

Since libusb 1.0 won't export the bus and device linked lists to
applications, you want to update those lists when you receive the
notifications while keeping any internal data structures locked, right?

JE

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt