device filtering support

[Pete Batard]

On 2012.02.03 12:17, Hans de Goede wrote:
>> 1. hotplug that doesn't rely on cross platform event handling (eg.
>> using callbacks only, as with the Nokia proposal)
>
> Hmm, if we do this before fixing 2, I assume that this means that the
> callbacks can
> (and will) be called from a different thread? This may come as an
> unpleasant
> surprise for Unix users of the API. I understand that this is
> unavoidable under
> Windows until we fix 2. But Unix users are used to not having to think
> about
> multi threadedness, instead relying on a select based loop.

Yeah. The problem is select is non-portable, so we can't really go 
adding platform specific items we're going to remove anyway. Callbacks 
have the advantage of being universal, even if they might require more 
effort on the user side for multithreading.

If you want, we can reword as:
1. single-threaded hotplug
2. cross platform event handling and hotplug refactoring for multi-threaded

I also wouldn't push for any "finalized" API at the very least until we 
have both #1 and #2 anyway. I also think all of 1, 2 & 3 should occur in 
a dev branch, and shouldn't be added into mainline until we have seen 
the complete result and are happy with it. The whole point is that we 
don't know where this whole exercise might lead us (maybe this approach 
is off, maybe we won't be able to avoid filtering), so better be careful 
presenting anything official too soon.

We could suffix _dev to any new API call from the dev branch, such as 
any hotplug callback API to make it clear that one should expect 
potential breakage or removal.

> So I think we need to make it really really really clear in the API docs
> that
> the device removed/added callbacks are called from a different thread, and
> add an option for Unix API users to disable this behavior. Of course the
> Unix API users need to use the pollfd "stuff" then to make sure the
> callbacks
> are called, but I think being able to this non multi-threaded is important
> for Unix users.

I don't have a problem with that, but hopefully there won't be too much 
of a wait between #1 and #2, so we can avoid adding temporary UNIX 
specific features. Currently I'm seeing the callback approach as a 
temporary stopgap so that we have all the pieces in place for #2.

Regards,

/Pete