[patch] Add eloop support for write & error socket callbacks

[Dan Williams]

On Tue, 2006-03-21 at 19:16 -0800, Jouni Malinen wrote:
> On Tue, Mar 21, 2006 at 06:21:25PM -0500, Dan Williams wrote:
> 
> > Patch attached, against current 0.4 HEAD.  Write and error callbacks are
> > needed for DBUS support, which I plan to add in the next month or so for
> > a DBUS-enabled control interface.
> 
> Thanks! The implementation itself looks fine, but I need to think about
> the interface bit more closely from the view point of non-UNIX systems
> that may not have select() or even BSD sockets.. The proposed changes
> would make this interface very similar to select() features and that may
> not be the best choice for this.

DBus, at least, uses the socket and select model anyway, which fits in
nicely here.  What OSs don't have select, other than some random
real-time ones?  What does moving off select() actually gain?  In any
case, if we don't have read/write/error, we'll need to figure out some
way to kludge that in.

Underneath, dbus opens a UNIX domain socket to the dbus daemon, and the
user (in this case wpa_supplicant) needs to monitor that socket for
read/write/error states.  So if there's some other mechanism used rather
than select(), the dbus code would still have to use select in some
fashion to even think of working.  We'd end up essentially polling that
socket anyway.

> > I'd rather have done one function for registering read, write, and error
> > callbacks and use an enum or something to figure out which type, but
> > that breaks source compatibility for the rest of the code and that
> > sucks.  This patch should work without changes to any part other than
> > eloop.
> 
> Indeed.. I would not accept this if all places using eloop would need to
> be changed. However, it should be possible to add a new function for
> doing the registration as long as the existing API is implemented as a
> wrapper on top of this new interface. This would allow new code to use
> the new function while the old code would still work as-is.
> 
> Using a single function for this and maybe even changing the callback
> functions to include an extra parameter, event type, could be a cleaner
> solution for this. There would be only one eloop_sock_table and it would
> have bitmask of which events (read/write/error) are registered to be
> received.

Is this a prerequisite for accepting the patch?  Seems fairly easy, so
I'll try that.

Dan