On Wed, Sep 12, 2012 at 4:40 PM, Pete Batard <p...@akeo.ie> wrote:
> On 2012.09.12 10:51, Hans de Goede wrote:
> >> should we add a new API even if we
> >> expect at least one for the platforms we support never to have any use
> >> for it?
> >
> > Yes, I want libusbx to enable app writers to do whatever they envision
> > and their chosen platform makes possible, rather then offer some sort of
> > lowest common denominator approach.
>
> Should have phrased my question better. This was about deciding when a
> call should become a global API one vs keeping it platform specific
> (either through #ifdef or ioctl). None of us wants to remove useful
> features, even if they apply to one platform.
>
> > Hmm, actually having a libusb_ioctl could work out nicely for platform
> > specific stuff. It feels a bit low-level-ish, where as in general we
> > try to offer a higher-level API. But then again these bits tend to be
> > pretty low-level stuff.
>
> That's how I see them too right now, at least from the ones we
> identified so far. I expect future calls to more or less fit that model
> too, but that's only a guess.
>
> > Sometimes a V2 ioctl gets introduced under Linux.
>
> No problem with that, and I expect us to have to do that as well
> eventually. But at least, it's a parameter rather than an API call.
>
> > I like what the v4l2
> > Linux subsystem does there, as you probably know, the way Linux ioctls
> > work is they take:
> >
> > Argument 1: a fd, would be a libusb_device_handle in our case
> > Argument 2: an int indicating which operation to do
> > Argument 3: a long giving the arguments to the operation, generally used
> to
> > pass a void *, so we should use a void *, as sizeof(long) != sizeof
> > (void *)
> > on some non Linux platforms.
>
> Yeah, avoid the long. We could use a uint_ptr (part of stdint.h and
> aimed at being cast to a pointer, regardless of 32/64). I think I'd tend
> to prefer using a void*, but either way is fine.
>
> MS does things a bit differently [1] (even if you ignore the
> OVERLAPPED), with different buffers for in and out, but I see that as a
> bit of an overkill when 3 arguments as proposed above should do just fine.
>
The advantage of the MS way is that the input buffer can be const void *
rather than just void *. I find it annoying to have to cast a 'const' away
in my code when my APIs are being careful to mark constant data as such.
For the same reason, I'd rather not use uint_ptr as it too introduces casts
if a pointer is being passed in.
As for the idea of libusb_ioctl() itself, I support it.
Orin.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
