libusb future

[Daniel Drake]

Hi all,

As Johannes Erdfelt wrote in a mail earlier today, I'm now in control of
the libusb project. libusb development has been stalled for several
months, mainly because Johannes does not currently have enough time to
work on the project.

I use libusb-0.1 in one of my projects, but decided to drop it as it was
lacking some functionality I wanted. I could not find any equivalent
libraries offering the feature set I was hoping for, so I sat down to
write my own USB access library. We later realised that the goals and
design principles of my own library fit in with the original libusb
ideas rather well, so it makes sense for my work to become the future
libusb.

Many thanks to Johannes for being open/flexible in this respect --
libusb is clearly his baby but he has been very co-operative in
transferring it given the project inactivity. I'll do my best to take
good care of it :)

A little about me: I'm a Linux kernel contributor and have worked on
various USB device drivers. I also lead Gentoo's kernel team. My current
project which inspired the new USB library is a fingerprint scanning
project: http://www.reactivated.net/fprint/

My plans for libusb:

1. I will undertake basic maintenance of the widely-used libusb-0.1
codebase - I'll apply simple patches and do infrequent releases.

2. The name of the existing libusb-1.0 development branch will be erased
from our brains (I'll leave the code in place for reference, but I do
not think this development branch will go anywhere). *zap*

3. I will rename my new USB library project (fpusb) to "libusb-1.0". In
other words, this can be viewed as a complete rewrite of libusb
(although with various borrowed code/ideas). The goals are basically to
provide asynchronous I/O capabilities in a lightweight library, while
offering poll fd's for decent mainloop integration. You can read a bit
more about my efforts here:
http://www.reactivated.net/fprint/wiki/Fpusb

I will elaborate more on the goals of libusb-1.0 in a future mail. Some
portability will be lost in the short term (it'll be Linux only), but I
hope to attract interest from developers experienced with USB I/O layers
of other operating systems, and with their help it will hopefully become
as portable as libusb-0.1. (If such people are interested already, I'd
suggest not doing anything more than looking at the code for now, give
the design a bit more time to settle first).

Things may start a little slowly as I have exams coming up very soon,
but things will progress given some time :)
I will send further mails over the next week or so describing my plans
for each branch in more detail.

Thanks,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Jan 2, 2008 8:24 AM, Daniel Drake <dsd@...> wrote:

> 3. I will rename my new USB library project (fpusb) to "libusb-1.0". In
> other words, this can be viewed as a complete rewrite of libusb
> (although with various borrowed code/ideas). The goals are basically to
> provide asynchronous I/O capabilities in a lightweight library, while
> offering poll fd's for decent mainloop integration. You can read a bit
> more about my efforts here:
> http://www.reactivated.net/fprint/wiki/Fpusb
>
> I will elaborate more on the goals of libusb-1.0 in a future mail. Some
> portability will be lost in the short term (it'll be Linux only), but I
> hope to attract interest from developers experienced with USB I/O layers
> of other operating systems, and with their help it will hopefully become
> as portable as libusb-0.1. (If such people are interested already, I'd
> suggest not doing anything more than looking at the code for now, give
> the design a bit more time to settle first).
>

Just wondering if the new libusb-1.0 can be made to be compatible with
libusb-win32 1.0 which is the new development version of libusb-win32.

Website (wiki): http://libusb-win32.wiki.sourceforge.net/
Developer: Stephan Meyer
0.1 branch API which is based on libusb API but adds isochronous transfer
and asynchronous I/O. It is already working quite well. So this is in line
with your goals.
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb/src/usb.h?view=markup

1.0 branch API which is basically compatible with the 0.1 API but adds
several backend (libusb-win32 device driver, native HID and WinUSB). It is
still under development.
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/src/dll/usb.h?view=markup

Why adds HID backend? Because HID driver is built in Windows 98 and later, it is
very popular for many USB device to disguise as USB device (just look at the
Linux HID blacklist). It is not that simple to detach the HID driver under
Windows without manual intervention so it makes sense to have an HID backend.
This might make sense for Linux in the future because of the upcoming
HID Simple Driver Interface (http://lkml.org/lkml/2007/3/5/20).
Even though HID API is quite platform specific, it is quite well understood
in major operating systems (Windows, Linux, BSDs, Solaris and Mac OS X)
so that it is possible to write a platform specific backend. This will help
libusb to solve one major problem for HID device: kernel HID driver detaching
is only possible under Linux using libusb API.

Why adds WinUSB for libusb-win32 1.0? It is to solve the Windows Vista 64
driver signing problem. The future usbfs is kind of similar to WinUSB (to
expose USB endpoints). So this might be kind of insiring as well.

I understand Windows and Linux are quite different and I am not a programmer
myself so I am not so sure if this is all feasible. But I just feel it is worth
considering.

Xiaofan
http://mcuee.blogspot.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Daniel Drake]

Xiaofan Chen wrote:
> Just wondering if the new libusb-1.0 can be made to be compatible with
> libusb-win32 1.0 which is the new development version of libusb-win32.

Thanks for the information. I'm certainly interested in having future
incarnations of libusb portable to windows, I'll spend some time looking
over that material sometime soon.

Cheers,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Daniel Drake wrote:
> As Johannes Erdfelt wrote in a mail earlier today, I'm now in control of
> the libusb project.
> ...
> 3. I will rename my new USB library project (fpusb) to "libusb-1.0". In
> other words, this can be viewed as a complete rewrite of libusb
> (although with various borrowed code/ideas). The goals are basically to
> provide asynchronous I/O capabilities in a lightweight library, while
> offering poll fd's for decent mainloop integration.

How open do you expect to be?  That is, do you expect to be a benevolent
dictator, having sole control over all aspects of the code base?  Or do
you expect it to be a cooperative development effort?

For example, in my opinion, many of your API names are not necessarily
intuitive; I couldn't guess what they do without consulting a
reference.  Part of that comes from abbreviating.  And what led you to
use "msg" to describe all of the USB transfers?  In the USB spec,
control pipes are the only ones that carry "messages".  Do you expect to
open this up for discussion?

This does not seem to support isochronous pipes yet.  Do you have a plan
for that?

And do we all expect to continue having both libusb and openusb
discussions on this one mailing list?  Personally, I think the
cross-pollenization is probably quite valuable.

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Daniel Drake]

Tim Roberts wrote:
> How open do you expect to be?  That is, do you expect to be a benevolent
> dictator, having sole control over all aspects of the code base?  Or do
> you expect it to be a cooperative development effort?

I hope for it to be cooperative, but I'm not sure how much I can expect
other people to contribute.

> For example, in my opinion, many of your API names are not necessarily
> intuitive; I couldn't guess what they do without consulting a
> reference.  Part of that comes from abbreviating.  And what led you to
> use "msg" to describe all of the USB transfers?  In the USB spec,
> control pipes are the only ones that carry "messages".  Do you expect to
> open this up for discussion?

Indeed, feedback is appreciated. I am not yet happy with the naming
aspects of the API which I have already meddled with a few times since
starting the project. Suggestions appreciated.

I can probably guess, but which parts did you find unintuitive?

Do you think I should refer to control transfers as "messages" but bulk
ones as something else? (i guess yes). libusb_submit_bulk_transfer()?
libusb_submit_bulk_urb()?

> This does not seem to support isochronous pipes yet.  Do you have a plan
> for that?

Yes, it's planned, just haven't gone as far to implement it yet. There
is certainly work to be done before this can be released as v1.0.

> And do we all expect to continue having both libusb and openusb
> discussions on this one mailing list?  Personally, I think the
> cross-pollenization is probably quite valuable.

Agreed, I'm sure we can learn from each other.

Thanks,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Daniel Drake wrote:
> Indeed, feedback is appreciated. I am not yet happy with the naming
> aspects of the API which I have already meddled with a few times since
> starting the project. Suggestions appreciated.
>
> I can probably guess, but which parts did you find unintuitive?
>  

Well, certainly the "poll" routines do not explain themselves.  I also
don't like "intr" and "devh".  And, since I'm getting picky,
fpusb_dev_get_descriptor implies that it will gets any kind of
descriptor (rather than just the device descriptor), and
fpusb_dev_get_config doesn't mention the word "descriptor".  You don't
have an API to fetch string descriptors yet, do you?

I like APIs that read like a sentence fragment, with a verb and a noun.

> Do you think I should refer to control transfers as "messages" but bulk
> ones as something else? (i guess yes). libusb_submit_bulk_transfer()?
> libusb_submit_bulk_urb()?
>  

Personally, I would refer to all of them as "transfers".  The message vs
stream distinction in the spec is not really very useful.  From a
software point of view, control, bulk, and interrupt transfers are
identical, except that some control transfers have a pre-defined format.

I'm torn about how to handle the naming of sync vs async routines, even
in my own code.  Although "libusb_submit_bulk_urb" accurately reflects
what the routine does, in fact the libusb user doesn't know about or
think in terms of URBs.  That is an implementation detail.

I could be talked into this:
    libusb_submit_bulk_transfer
    libusb_submit_bulk_transfer_async
or this:
    libusb_submit_bulk_transfer_and_wait
    libusb_submit_bulk_transfer

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Jan 3, 2008 7:16 AM, Tim Roberts <timr@...> wrote:

> I'm torn about how to handle the naming of sync vs async routines, even
> in my own code.  Although "libusb_submit_bulk_urb" accurately reflects
> what the routine does, in fact the libusb user doesn't know about or
> think in terms of URBs.  That is an implementation detail.
>
> I could be talked into this:
>     libusb_submit_bulk_transfer
>     libusb_submit_bulk_transfer_async
> or this:
>     libusb_submit_bulk_transfer_and_wait
>     libusb_submit_bulk_transfer
>

libusb-win32 0.1 has already implemented isochronous transfer and asynchronous
 I/O support.

http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/src/dll/usb.h?view=markup

int usb_isochronous_setup_async(usb_dev_handle *dev, void **context,
                                   unsigned char ep, int pktsize);
int usb_bulk_setup_async(usb_dev_handle *dev, void **context,
                           unsigned char ep);
int usb_interrupt_setup_async(usb_dev_handle *dev, void **context,
                                unsigned char ep);

int usb_submit_async(void *context, char *bytes, int size);
int usb_reap_async(void *context, int timeout);
int usb_reap_async_nocancel(void *context, int timeout);
int usb_cancel_async(void *context);
int usb_free_async(void **context);

How do you like the above names?

Xiaofan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Xiaofan Chen wrote:

>
> libusb-win32 0.1 has already implemented isochronous transfer and asynchronous
>  I/O support.
>
> http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/src/dll/usb.h?view=markup
>
> int usb_isochronous_setup_async(usb_dev_handle *dev, void **context,
>                                    unsigned char ep, int pktsize);
> int usb_bulk_setup_async(usb_dev_handle *dev, void **context,
>                            unsigned char ep);
> int usb_interrupt_setup_async(usb_dev_handle *dev, void **context,
>                                 unsigned char ep);
>
> int usb_submit_async(void *context, char *bytes, int size);
> int usb_reap_async(void *context, int timeout);
> int usb_reap_async_nocancel(void *context, int timeout);
> int usb_cancel_async(void *context);
> int usb_free_async(void **context);
>  

That's an interesting approach.  The first three routines essentially
create "pipe handles", so that a single routine can do all of the URB
submission.

Because of that, I think I would have used names more like
"usb_create_pipe_handle".  After all, the "usb_xxx_setup_async" routines
aren't really setting up a request.  And, of course, the last 5 APIs
don't have any nouns, so it isn't clear what is being reaped, canceled,
or freed.

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Daniel Drake]

Tim Roberts wrote:
> Well, certainly the "poll" routines do not explain themselves.

I'm not sure how I can make these ones better. Use the word "iterate"
instead of poll?

Given that this function will only be called by async users (i.e.
advanced users) the naming here probably isn't too important -- they
will have to read the docs to understand how to properly integrate
asynchronous I/O into their application.

> I also
> don't like "intr" and "devh".

intr --> interrupt, that's easy.

devh --> dev_handle?

The main reason for these abbreviations is that I felt that function
names were becoming too long. Some of these are going to be called a lot
by applications.  I guess there's a balance to be met but I guess I may
have gone too far on the shortening approach.

> And, since I'm getting picky,
> fpusb_dev_get_descriptor implies that it will gets any kind of
> descriptor (rather than just the device descriptor), and
> fpusb_dev_get_config doesn't mention the word "descriptor".

Picky is good. I did throw in those functions rather quickly, will give
them more sensible names.

> You don't have an API to fetch string descriptors yet, do you?

Not yet.

> I'm torn about how to handle the naming of sync vs async routines, even
> in my own code.  Although "libusb_submit_bulk_urb" accurately reflects
> what the routine does, in fact the libusb user doesn't know about or
> think in terms of URBs.  That is an implementation detail.
>
> I could be talked into this:
>     libusb_submit_bulk_transfer
>     libusb_submit_bulk_transfer_async
> or this:
>     libusb_submit_bulk_transfer_and_wait
>     libusb_submit_bulk_transfer
>

Will give that some more thought. For the sync case I am quite fond of
the style of simplistic synchrnous function names used in both
libusb-0.1 and in the kernel itself e.g. usb_control_msg(). Simple
function names for simple users of the library :)

*thinks*

Any comments on:
  libusb_bulk_transfer()
  libusb_async_bulk_transfer()

One other thing I am slightly torn about is naming functions in terms of
the 'thing' that they operate on (or return). For example, libusb-0.1
does usb_open() and usb_close() but at the moment in fpusb I do
fpusb_devh_open() and fpusb_devh_close() because they deal with device
handles. Then there's fpusb_devh_claim_intf() etc.

(this is subject to change based on further thinking on my part or
influential discussions like this one)

But then there are other functions that I don't name like that because
it either doesn't seem appropriate or just doesn't seem right. For
example the transfer functions. Do you have any opinions on naming
styles here and where the balance should be?

Thanks for the feedback - much appreciated.
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Jan 3, 2008 7:47 AM, Tim Roberts <timr@...> wrote:

> Xiaofan Chen wrote:
> >
> > libusb-win32 0.1 has already implemented isochronous transfer and asynchronous
> >  I/O support.
> >
> > http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/src/dll/usb.h?view=markup
> >
> > int usb_isochronous_setup_async(usb_dev_handle *dev, void **context,
> >                                    unsigned char ep, int pktsize);
> > int usb_bulk_setup_async(usb_dev_handle *dev, void **context,
> >                            unsigned char ep);
> > int usb_interrupt_setup_async(usb_dev_handle *dev, void **context,
> >                                 unsigned char ep);
> >
> > int usb_submit_async(void *context, char *bytes, int size);
> > int usb_reap_async(void *context, int timeout);
> > int usb_reap_async_nocancel(void *context, int timeout);
> > int usb_cancel_async(void *context);
> > int usb_free_async(void **context);
> >
>
> That's an interesting approach.  The first three routines essentially
> create "pipe handles", so that a single routine can do all of the URB
> submission.
>
> Because of that, I think I would have used names more like
> "usb_create_pipe_handle".  After all, the "usb_xxx_setup_async" routines
> aren't really setting up a request.  And, of course, the last 5 APIs
> don't have any nouns, so it isn't clear what is being reaped, canceled,
> or freed.
>

To be honest, I do not quite understand isochronous transfer
(I was struggling to learn to write a host program to talk to
a bare-minimum isochronous transfer USB device in the
Microchip forum post) and asynchronous I/O works under
libusb-win32. I only know it is working since I tried out an example
(modified from the example given by Stephan Meyer).

http://www.nabble.com/Understanding-iIsochronous-transfer-with-libusb-win32-to11916957.html
http://forum.microchip.com/tm.aspx?m=270049&mpage=2

Part of the problem is my lack of knowledge, part of the
problem is the lack of documentation. Maybe you can look
into the codes to know how it works since you an an expert
for USB drivers under Windows.

Xiaofan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Daniel Drake wrote:
> Tim Roberts wrote:
>  
>> Well, certainly the "poll" routines do not explain themselves.
>>    
>
> I'm not sure how I can make these ones better. Use the word "iterate"
> instead of poll?
>  

Describe what they actually DO in a sentence.
"fpusb_wait_request_complete"?  "fpusb_wait_for_queue_empty"?  I tried
to trace through the code in io.c a little, but since all the return
types are int, I'm not sure what's actually being passed around.

> Given that this function will only be called by async users (i.e.
> advanced users) the naming here probably isn't too important -- they
> will have to read the docs to understand how to properly integrate
> asynchronous I/O into their application.
>  

History shows that what they will ACTUALLY do is post to this mailing
list saying "I want to do asynchronous USB I/O please help me send me
code it should be easy Im in a hurry thx."

> The main reason for these abbreviations is that I felt that function
> names were becoming too long. Some of these are going to be called a lot
> by applications.  I guess there's a balance to be met but I guess I may
> have gone too far on the shortening approach.
>  

In my opinion, yes.  Most programmers' editors have auto word completion
now, so typing long function names is not the burden it once was.  The
benefit is that your code reads like a prose paragraph.

> Any comments on:
>   libusb_bulk_transfer()
>   libusb_async_bulk_transfer()
>  

I'd be fine with that.

> One other thing I am slightly torn about is naming functions in terms of
> the 'thing' that they operate on (or return). For example, libusb-0.1
> does usb_open() and usb_close() but at the moment in fpusb I do
> fpusb_devh_open() and fpusb_devh_close() because they deal with device
> handles. Then there's fpusb_devh_claim_intf() etc.
>  

Yes, it's a difficult balance.  One thing to remember is that EVERYTHING
uses a device handle.  Because of that, I'm not sure it's really
necessary to mention it in the API.  At the very least, I don't think
there is any potential confusion between "device" and "device handle"
here, and "dev" certainly reads better than "devh".

> But then there are other functions that I don't name like that because
> it either doesn't seem appropriate or just doesn't seem right. For
> example the transfer functions. Do you have any opinions on naming
> styles here and where the balance should be?
>  

The name should reflect what is being done.  A bulk transfer isn't
really being "done" to the device handle, although it is certainly a
critical part of doing it.

One example of taking this to an extreme is Microsoft's new driver
model, KMDF.  Underneath, it's written in C++, but the official API is
in C.  The API name always includes the class where the method would
have been.  So, the wrapper for IoCompleteRequest is WdfRequestComplete
(which works on a WDFREQUEST object).  Instead of  IoCallDriver to
submit a request, you use WdfIoTargetSendIoctlSynchronously, because the
request gets sent to a WDFIOTARGET object.

KMDF takes things to the extreme.  Your fingers do get a bit tired of
typing WdfIoTargetSendInternalIoctlOthersSynchronously,
WdfIoTartgetFormatRequestForInternalIoctlOthers,
WdfRequestRetrieveUnsafeUserInputBuffer,
WdfRequestProbeAndLockUserBufferForRead, and
WdfDeviceInitRegisterPnpStateChangeCallback, but it's also very easy to
guess the name of the API you need at any given point, and the code does
read pretty well.

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  

Wow!  THAT surprises me.

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Daniel Drake]

Tim Roberts wrote:
> Describe what they actually DO in a sentence.

That's not easy.

> "fpusb_wait_request_complete"?  "fpusb_wait_for_queue_empty"?  I tried
> to trace through the code in io.c a little, but since all the return
> types are int, I'm not sure what's actually being passed around.

It's a "do what needs to be done" function.
libusb_do_stuff_if_stuff_needs_to_be_done() :)

The library does not create any threads and hence does not "run" except
for the times when the application calls into it.

Of course, during the time when the application is not calling into the
library, USB-related things may happen. Devices may be plugged or
disconnected. URBs may complete. etc.

The library needs to be called into to handle such events. This is
fpusb_poll().

The question is now: how often should apps call this function? Is there
that apps can detect exactly when the function needs to be called?

Naively, applications can just call this function every (say) 0.2
seconds. But's that ugly and hurts battery life now that we have dynamic
ticks on Linux. Hence one of the driving design principles for this
library is to provide a set of file descriptors that can be passed to
poll() or select() in the application's main loop.

When activity is detected on the exposed file descriptors, the
application is expected to call into the library using
fpusb_poll_timeout(0).

The application does not need to call into the library at any other
time. This is how we efficiently integrate asynchronous I/O with single
threaded apps, since they will be select()ing a few other file
descriptors in their main loop anyway. For applications where that is
not true, they can easily create a thread that calls fpusb_poll() in a loop.

As for naming, well,  I'm still not really sure. Part of the problem is
probably down to the bad naming of poll() and select().  I'm sure you
have some words to be said about naming a function "select". And poll()
is often used as an *alternative* to polling, but it's not really
polling, it's more of an informed wakeup since it's implemented at the
kernel level and integrated with the scheduler, so really no polling
happens in most cases.

> History shows that what they will ACTUALLY do is post to this mailing
> list saying "I want to do asynchronous USB I/O please help me send me
> code it should be easy Im in a hurry thx."

Not sure what we can do about that. If it's happened before, it's going
to continue regardless of what the functions are named. It's going to be
necessary to read the docs to understand how to do async I/O.

> Yes, it's a difficult balance.  One thing to remember is that EVERYTHING
> uses a device handle.  Because of that, I'm not sure it's really
> necessary to mention it in the API.  At the very least, I don't think
> there is any potential confusion between "device" and "device handle"
> here, and "dev" certainly reads better than "devh".

But we already have both, where both are different things...
dev is a "discovered device" from fpusb_get_devices().
You then open a dev to get a devh, which you can perform the interesting
functions on.

I don't particularly like the name "device handle" but I think it's
necessary to distinguish between these 2, unless you have new ideas?

Thanks for your input.
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[msoumen]

Hi Drake,

I am so glad to read this. Thanks for getting the libusb machine going.
I was disappointed once learnt that libusb is frozen. But then Kudos to
Johannes Erdfelt and you for taking the positive step in going ahead
with libusb development. Libusb is a great piece of code and I ernestly
feel it can be made much better if steps taken.

Thank you,
Soumen

Daniel Drake wrote:

>Hi all,
>
>As Johannes Erdfelt wrote in a mail earlier today, I'm now in control of
>the libusb project. libusb development has been stalled for several
>months, mainly because Johannes does not currently have enough time to
>work on the project.
>
>I use libusb-0.1 in one of my projects, but decided to drop it as it was
>lacking some functionality I wanted. I could not find any equivalent
>libraries offering the feature set I was hoping for, so I sat down to
>write my own USB access library. We later realised that the goals and
>design principles of my own library fit in with the original libusb
>ideas rather well, so it makes sense for my work to become the future
>libusb.
>
>Many thanks to Johannes for being open/flexible in this respect --
>libusb is clearly his baby but he has been very co-operative in
>transferring it given the project inactivity. I'll do my best to take
>good care of it :)
>
>A little about me: I'm a Linux kernel contributor and have worked on
>various USB device drivers. I also lead Gentoo's kernel team. My current
>project which inspired the new USB library is a fingerprint scanning
>project: http://www.reactivated.net/fprint/
>
>My plans for libusb:
>
>1. I will undertake basic maintenance of the widely-used libusb-0.1
>codebase - I'll apply simple patches and do infrequent releases.
>
>2. The name of the existing libusb-1.0 development branch will be erased
>from our brains (I'll leave the code in place for reference, but I do
>not think this development branch will go anywhere). *zap*
>
>3. I will rename my new USB library project (fpusb) to "libusb-1.0". In
>other words, this can be viewed as a complete rewrite of libusb
>(although with various borrowed code/ideas). The goals are basically to
>provide asynchronous I/O capabilities in a lightweight library, while
>offering poll fd's for decent mainloop integration. You can read a bit
>more about my efforts here:
>http://www.reactivated.net/fprint/wiki/Fpusb
>
>I will elaborate more on the goals of libusb-1.0 in a future mail. Some
>portability will be lost in the short term (it'll be Linux only), but I
>hope to attract interest from developers experienced with USB I/O layers
>of other operating systems, and with their help it will hopefully become
>as portable as libusb-0.1. (If such people are interested already, I'd
>suggest not doing anything more than looking at the code for now, give
>the design a bit more time to settle first).
>
>Things may start a little slowly as I have exams coming up very soon,
>but things will progress given some time :)
>I will send further mails over the next week or so describing my plans
>for each branch in more detail.
>
>Thanks,
>Daniel
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2005.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Libusb-devel mailing list
>Libusb-devel@...
>https://lists.sourceforge.net/lists/listinfo/libusb-devel
>  
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[j miller]

I've been using libusb for a couple years...

Please, please, make the linux API "like" the win32 API (both might need
changes).  Common API, use the same names, and for the linux only,
preface each call with "linux_" and for win32 specific "win32_" (or
something like this).

This would make is MUCH easier for code that's written to run in both
linux and win32..

Soumen Mondal wrote:

> Hi Drake,
>
> I am so glad to read this. Thanks for getting the libusb machine going.
> I was disappointed once learnt that libusb is frozen. But then Kudos to
> Johannes Erdfelt and you for taking the positive step in going ahead
> with libusb development. Libusb is a great piece of code and I ernestly
> feel it can be made much better if steps taken.
>
> Thank you,
> Soumen
>
> Daniel Drake wrote:
>
>> Hi all,
>>
>> As Johannes Erdfelt wrote in a mail earlier today, I'm now in control of
>> the libusb project. libusb development has been stalled for several
>> months, mainly because Johannes does not currently have enough time to
>> work on the project.
>>
>> I use libusb-0.1 in one of my projects, but decided to drop it as it was
>> lacking some functionality I wanted. I could not find any equivalent
>> libraries offering the feature set I was hoping for, so I sat down to
>> write my own USB access library. We later realised that the goals and
>> design principles of my own library fit in with the original libusb
>> ideas rather well, so it makes sense for my work to become the future
>> libusb.
>>
>> Many thanks to Johannes for being open/flexible in this respect --
>> libusb is clearly his baby but he has been very co-operative in
>> transferring it given the project inactivity. I'll do my best to take
>> good care of it :)
>>
>> A little about me: I'm a Linux kernel contributor and have worked on
>> various USB device drivers. I also lead Gentoo's kernel team. My current
>> project which inspired the new USB library is a fingerprint scanning
>> project: http://www.reactivated.net/fprint/
>>
>> My plans for libusb:
>>
>> 1. I will undertake basic maintenance of the widely-used libusb-0.1
>> codebase - I'll apply simple patches and do infrequent releases.
>>
>> 2. The name of the existing libusb-1.0 development branch will be erased
>>from our brains (I'll leave the code in place for reference, but I do
>> not think this development branch will go anywhere). *zap*
>>
>> 3. I will rename my new USB library project (fpusb) to "libusb-1.0". In
>> other words, this can be viewed as a complete rewrite of libusb
>> (although with various borrowed code/ideas). The goals are basically to
>> provide asynchronous I/O capabilities in a lightweight library, while
>> offering poll fd's for decent mainloop integration. You can read a bit
>> more about my efforts here:
>> http://www.reactivated.net/fprint/wiki/Fpusb
>>
>> I will elaborate more on the goals of libusb-1.0 in a future mail. Some
>> portability will be lost in the short term (it'll be Linux only), but I
>> hope to attract interest from developers experienced with USB I/O layers
>> of other operating systems, and with their help it will hopefully become
>> as portable as libusb-0.1. (If such people are interested already, I'd
>> suggest not doing anything more than looking at the code for now, give
>> the design a bit more time to settle first).
>>
>> Things may start a little slowly as I have exams coming up very soon,
>> but things will progress given some time :)
>> I will send further mails over the next week or so describing my plans
>> for each branch in more detail.
>>
>> Thanks,
>> Daniel
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Libusb-devel mailing list
>> Libusb-devel@...
>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>  
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Mike Lewis]

On Jan 3, 2008 1:19 AM, j miller <jmiller@...> wrote:

I've been using libusb for a couple years...

Please, please, make the linux API "like" the win32 API (both might need
changes).  Common API, use the same names, and for the linux only,
preface each call with "linux_" and for win32 specific "win32_" (or
something like this).

This would make is MUCH easier for code that's written to run in both
linux and win32..

That is the plan for OpenUSB. I'm not sure where the backend of  win32 stands, but it should be coming along...  and you'll get your wish.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Daniel Drake]

j miller wrote:
> I've been using libusb for a couple years...
>
> Please, please, make the linux API "like" the win32 API (both might need
> changes).  Common API, use the same names, and for the linux only,
> preface each call with "linux_" and for win32 specific "win32_" (or
> something like this).

Yes, I plan to design this like a proper abstraction layer (like the
previous libusb devel branch) rather than having several
somewhat-separated implementations of the same library as in 0.1.

Thanks,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel