headers
Peter Stuge | 1 May 2007 01:25

Re: _devid_t and _device_t and a bit of void

On Mon, Apr 30, 2007 at 03:44:03PM -0700, Michael Bender wrote:
> If a library is properly documented (and assuming that the library
> implements the documented behavior), then why do you ever need to
> look at the sources of the library?

I agree completely.

> The application is not "smarter" than the library, and it has
> absolutely no business screwing around with private library data.

Also fully agreed.

> > The library is not distinct from the application.
> 
> That's a cop-out answer. libusb should ideally never coredump due
> to internal programming errors or due to the application
> manipulating internal library state when it has no business doing
> so. Back to my libc example - how many times have you ever had libc
> coredump other than when you have fed it garbage?

Once so far. But I agree with your point completely.

> >>> Ouch no this is the opposite of what I would like to see. Just
> >>> let the pointer serve as the hash?
> >> you lose sanity checking then
> > 
> > That's fine. I'm willing to sacrifice this isolation for the huge
> > increase in ease of use.
> 
> I don't get it - what's the ease of use issue you're talking about
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Stuge | 1 May 2007 01:28

Re: Data types and their names

On Mon, Apr 30, 2007 at 09:59:07AM -0700, Tim Roberts wrote:
> Peter Stuge wrote:
> > I guess it could be investigated whether all characters in all
> > languages supported by USB actually are within plane 0. If they
> 
> Right.  As I said, the USB 2.0 spec calls out "Unicode 3.0".

Yep, I even quoted it in a previous message.

> The Unicode 3.0 standard does not include anything beyond plane 0.

I didn't know that, that's good news! :)

//Peter

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 0 comments |
headers
Peter Stuge | 1 May 2007 01:36

Re: [PATCH] bsd.c: Return actual length from usb_bulk_write / usb_control_msg

On Wed, Apr 25, 2007 at 10:09:31AM +0200, Max Vozeler wrote:
> the BSD versions of usb_bulk_write() and usb_control_msg() currently
> return the number of bytes requested rather than the number of bytes
> actually transferred. The attached patch changes them to return the
> real lengths, which matches the behaviour on Linux.

Johannes, could you commit this patch?

There will probably be at least one more libusb 0.1 release.

//Peter

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 0 comments |
headers
frits vanderlinden | 1 May 2007 01:40
Favicon

Re: Pipes and request structs

Peter Stuge wrote:
> Getting verbose since it's the only way I seem able to make my point.
> 
> 
I am not sure that it helps because we are still not clear :-(

> On Mon, Apr 30, 2007 at 08:11:46PM +0800, Sophia Li wrote:
>>>>> I want the library to pick the right type depending on the
>>>>> endpoint.
>> Sorry, but endpoint address doesn't contain transfer type
>> information. The information is contained in bmAttributes in
>> endpoint desc. You need to get endpoint desc for deciding the type.
>> That is a big inconvenience.
> 
> Yes, I mentioned this two or three times already. I want the library
> to get the descriptor automatically.
> 
> 
>> Why change all our previous design just for saving a type member in
>> the struct?
> 
> That's not it. I made an analogy to system fd:s but I guess noone
> picked up on it.
> 

we are not going to get it unless you come up with function prototypes
that illustrate what you are really proposing.

> 
> On Sun, Apr 29, 2007 at 04:27:18PM -0700, frits vanderlinden wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
frits vanderlinden | 1 May 2007 01:41
Favicon

Re: _devid_t and _device_t and a bit of void

Peter Stuge wrote:
> On Mon, Apr 30, 2007 at 08:42:09PM +0800, Sophia Li wrote:
>> I would like to mention the original idea of libusb 1.0 design is
>> to make libusb MT-safe.
> 
> This is a good design goal that we should indeed meet. It is best met
> by providing means for multiple threads to use the library
> simultaneously. This may require duplicating some data and/or locking
> in the application.
> 
> 
>> One way to achieve MT-safe is not to export libusb internal data
>> structures to user, so that user won't be able to modify the data
>> strucutures while libusb is doing so.
> 
> Sorry, but this is just not true.
> 
indeed

> The user can create a new thread and write all over the struct while
> the library is busy doing something with it and the library has no
> way to stop it from happening.
> 
> 
each thread has its own data. no data is shared between threads. no data
is exposed. The only global data is probably the device list

> The solution is not to try to make it impossible to create a broken
> application, but to teach people (education and documentation)
> how to create working applications.
(Continue reading)

Permalink | Reply | 0 comments |
headers
frits vanderlinden | 1 May 2007 01:41
Favicon

Re: Device discovery: coldplug

Peter Stuge wrote:
> On Sun, Apr 29, 2007 at 12:38:14AM -0700, Michael Bender wrote:
>> Are you saying that code that registers a callback handler and has
>> that callback handler note when a device comes and goes and sets
>> appropriate state is really that much more difficult than code that
>> just scans a device list once?
> 
> I think the argument is that it is nice to offer a fully usable
> library API even for single threaded application, even at the cost
> of reduced functionality.
> 

agreed

> It's nice to not require library users to be comfortable with
> multi-threaded programming.
> 

yup, if I just want to write a simple test program and there is only one
device on the bus, I do not want to deal with all this overhead.

> On Mon, Apr 30, 2007 at 09:46:11AM -0700, Tim Roberts wrote:
>> Who is going to be responsible for doing all of that?
> 
> I think the application is responsible for taking care of the REMOVE
> event, stopping whatever it does, and likewise for taking care of
> ATTACH events and then start doing it's thing on the new device.
> 

there will always be window that the device is gone and the callback
(Continue reading)

Permalink | Reply | 4 comments |
headers
frits vanderlinden | 1 May 2007 01:41
Favicon

Re: Device discovery: coldplug

Peter Stuge wrote:
>
> In my original proposal I suggested that after all COLDPLUG events
> there would be a final event with COLDPLUG|ATTACH as the event type.
> 
> (Note that this means that the event type is changed to a bit field.)
> 
> Frits wanted to use ATTACH also for coldplug events and I'm OK with
> that, then the final event type would be ATTACH|REMOVE or a new
> END_OF_COLDPLUG (then the event type doesn't have to be a bitfield)
> instead.
> 

I don't think that is needed but I am not opposed. THe implementation
does need to insure that any hot removal events occur after the last
cold plug event.

> 
>> Do you mean COLDPLUG events only happen once and all together
>> right after event callbacks are set?
> 
> Yes, but a final event is still required to signal end-of-coldplug.
> 
> It's useful for the reason above. On a huge system it may not be
> neat to redraw a GUI for each coldplug ATTACH event when it is known
> that all of them will happen right after each other.
> 
yup, that is a very good reason.

> I don't feel too strongly about the filter functions, if you prefer
(Continue reading)

Permalink | Reply | 0 comments |
headers
frits vanderlinden | 1 May 2007 01:41
Favicon

Re: Device discovery: coldplug


>> That is more work in the OS. Hot removal of a PCMCIA card with USB host 
>> controller in is still not supported on Solaris. Don't know how well it 
>> works on other operating systems.
> 
> Works without any change or problem on Linux, which is good as that is
> how all of the modern celluar-wireless-network cards work these days :)
> 
>
not sure what you mean.  If a host controller gets removed, libusb needs
to do all the work to create detach events and update its device list

cheers

fritS

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 3 comments |
headers
frits vanderlinden | 1 May 2007 01:41
Favicon

Re: Device discovery: coldplug

Sophia Li wrote:
>
>> If a user yanks a PCMCIA card with a hostcontroller on it, libusb should 
>> generate removal events for each devid with that busid and finally the 
>> busid itself (the host controller has been removed so it cannot generate 
>>   detach events anymore). Therefore it is mandatory to have busid 
>> events, IMHO.
>>
> 
> That is more work in the OS. Hot removal of a PCMCIA card with USB host 
> controller in is still not supported on Solaris. Don't know how well it 
> works on other operating systems.
> 

That is an implementation detail. The API should support hot removal of
an host controller

[I actually believe that hot removal of PCMCIA is support on Solaris.
please check with colin]

cheers

fritS

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
(Continue reading)

Permalink | Reply | 0 comments |
headers
frits vanderlinden | 1 May 2007 01:41
Favicon

Re: _devid_t and _device_t and a bit of void

Peter Stuge wrote:
> On Sun, Apr 29, 2007 at 03:25:01PM -0700, frits vanderlinden wrote:
>>> What is the benefit of getters over a struct member that can be
>>> accessed directly?
>> I only want to hide private data and I do see a big advantage in
>> unique IDs. Libusb can then easily verify that it is the right type
>> which libusb can't do if you are passing pointers.
>> This makes debugging libusb much easier.
> 
> These are all benefits only for the library implementation which
> should not matter very much at this point. Are there any benefits
> for the library user?
> 
much easier debugging because libusb never chokes, never coredumps

> 
>> libusb returns invalid argument instead coredumping :-)
> 
> This is a nice idea, but it has two problems;
> 
> 1. The library is not distinct from the application.
>    (the problem is in the application)
> 

libusb should do as much as possible that it won't choke on garbage IN

> 2. The cost doesn't outweigh the very small potential benefit.
> 

There is massive benefit that libusb will always inform the user that
(Continue reading)

Permalink | Reply | 1 comment |

Gmane