Re: [Libusb-devel] Mac OS libusb_open() time

[Nathan H. <hj...@me...>]

I don't yet know what I want to use to store devices references. I will probably wait until we are ready to move on hotplug support to make a decision. I will do some testing in the meantime to see what would fit best.

For now I may add a reference to the device location to the matching dictionary passed to IOServiceGetMatchingServices. This may or may not be faster than iterating through the devices on the libusb side.

-Nathan

On Feb 27, 2011, at 4:02 PM, Pete Batard wrote:

> On 2011.02.27 02:49, Segher Boessenkool wrote:
>> Yes, and?  The problem here is not to use a hash -- unless you *make*
>> it a problem by insisting on some generic hash thing.
> 
> I'm not insisting. I asked a simple question, to Nathan, and by 
> extension to Linux people (if they _wanted_ to look into what may become 
> our Linux HP implementation), as to whether they thought having hash 
> table functions in core (which I picked up from glibc by the way - 
> they're not even homegrown) could prove helpful.
> 
> "I have pipe wrench to spare. Anybody think they could use a pipe 
> wrench? If not, I'll just keep it in my toolbox for now...".
> All I asked.
> 
> Now, if you want to answer "Nobody wants your lousy pipe wrench - and 
> you're a idiot for proposing it", that's your right, and point taken. 
> But I'll still rather wait for the go around to be complete, to decide 
> what I do with it. One person still hasn't spoken.
> 
>> No, that's not the game you can play, unless you propose taking
>> over maintainership from Peter?
> 
> Glad you asked, so that I can clarify this item, since I believe there 
> might be a few people thinking that I want to take over things.
> 
> As much as I'd like to go all Palpatine on libusb, and make it enter a 
> new reign of terror, I do not, under any circumstances, want to become a 
> libusb maintainer.
> 
> Now, this being said, do I think I would do a much better job than 
> Peter? Hell yes! I'd place RERO and timely releases, instead of 
> ill-placed cleanliness or a vision of "pure" software that ignores users 
> requests, as a priority, which I am confident would help provide quality 
> software that both meets our users requirement as well as make libusb 
> contributors feel welcome here (i.e. no having to wait weeks or months 
> for their patches to be processed, which is what Hans, Nokia and others 
> have had or are currently going through).
> But do I think I would be a good maintainer? Hell no! We need people 
> experienced for this job, like yourself or Enrico, and a lot more 
> impartial or less troublesome than I am.
> 
>>> In case you haven't noticed, what bogs down libusb is that we have too
>>> many things up in the air for the libusb maintainers to handle them all
>> 
>> Including various older stuff, and half-baked stuff.  If there is
>> something you want included that is not yet included, send a tested
>> patch against mainline,
> 
> I did. Repeatedly. And they got nowhere. So excuse me for being cautious 
> about wanting to trust the line above once again.
> 
>> it will be *much* easier to include it in
>> mainline that way (just "|git am" in your mail reader, or whatever
>> Peter uses for that; *much* less work than looking at some old
>> patch, figuring out if anyone liked or disliked it, what tree it
>> originally applied against, if it still applies cleanly, and it
>> still works correctly.
> 
> Where did you get the idea that I was asking any maintainers to pick up 
> old patches? That there were unresolved contentions points, linked to 
> old patches, that needed further discussion does not mean that, once 
> solved, libusb maintainers should go back and fetch these 3-4 month old 
> patch. Heck, I've been resubmitting the Windows patchset over and over 
> again when I felt there was a window to do so. Why would I stop?
> 
> As I said elsewhere, if you want patches against mainline, I don't have 
> much of an issue producing them at short notice. The only issue is that, 
> from looking at all the unresolved stuff we still had, it really didn't 
> make sense to me to try my luck again.
> 
>> The only downside is slightly higher mail volume.
>> 
>>> But of course, the real kicker is, Nokia _did_ post a patch, pretty much
>>> the way you want, against 1.0.8, back in August [1].
>> 
>> You didn't read what I said, did you.
> 
> I did read it. On the contrary, you clearly didn't read what I said 
> because if you did hen the answer to your question:
> 
>> Do they (or anyone else)
>> post improved versions of that patch now?
> 
> would be explicit. Why would Nokia do so when Peter explicitly told them 
> that, as long as Windows wasn't sorted, hotplug would have to wait?
> 
>> If not, why on earth should Peter do the work to merge it?
> 
> Again, where on earth did you get the idea that I am asking Peter to 
> merge an old patch which he already rejected? Now, if you want an 
> improved version of the Nokia patch against mainline, I can easily 
> produce one after I'm done with the other stuff. No bother.
> 
>> Sheesh, relax.  I was merely pointing out what _you_ can do to
>> Complaining he does not do his job does not help;
> 
> You don't understand, so let me make that clear.
> 
> I'm not complaining that Peter doesn't do his job. I am complaining 
> that, as far as I am concerned, he is doing a _bad_ job, with evidence 
> to back it up taken from his various actions over the past year. I'm 
> sorry to say that, but I see most of the difficulties we have into 
> moving libusb forward as the result of Peter's actions (or lack thereof) 
> and inflexibility on matters where a good maintainer should be flexible. 
> Therefore I don't see it as a matter of making it easier on him, but 
> it's a matter of making him change his approach to maintenance, so that 
> we have a maintainer that actually does what I consider a proper job for 
> a change (and I'm quite glad you joined to help there, though, after a 
> few months, not much seems to have changed)
> 
> Now, if you want to pretend that unilaterally rushing the removal of 
> HID, because nobody else on this list thought that there was much point 
> of removing it before the next release, just for the sake of 
> "cleanliness", is the mark of a good maintainer, be my guest.
> 
> When I see someone that I think does a bad job, I'm not going to beat 
> about the bush. And when I consistently see it occur, over the course of 
> a year, with next to no improvement, I might not be as patient with this 
> as other people would.
> 
> Regards,
> 
> /Pete
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel