infiniband: ?

[tridge at samba.org]

Peter,

Thanks for the update!

I think what you need to do next is to create a bzr branch of the ctdb
prototype I've done and start filling in an ib/ directory. Are you
familiar with what you need to do with bzr? (I'd be happy to give you
a few line example if it would help).

I think that enough is abstracted out in the ctdb tcp prototype to
start usefully filling in other transports. I expect it will also need
either a --with-infiniband configure option or some autoconf tests so
we can still build on systems without the various ib libraries.

 > I've noticed you already have some dynamic fd handling functions (e.g. 
 > std_event_add_fd). I also defined such callbacks on this interface.
 > What I'm suspecting missing from your side is std_event_remove_fd. (see your 
 > event_ops) - probably not an urgent issue, I'd use it only at program finish.

you don't need to define any of those in the ib code. The event_*()
functions are part of the events library that I have borrowed from
Samba4 for the ctdb prototype. It's a fully working events library. It
doesn't have a event_remove_fd() function as it uses talloc to release
a event handler. So you do this:

	/* add a handler for an event */
	fde = event_add_fd(ctdb->ev, in, in->fd, EVENT_FD_READ, 
		     ctdb_tcp_incoming_read, in);	

	/* do some work */
	....

	/* remove the handler */
	talloc_free(fde);

So I'm expecting that your ib code will call the same event_*()
functions that my tcp prototype calls. That way we never directly
expose the ctdb layer to the file descriptors that the transports need
- the transports just register whatever collection of events they
need, and the events system ensures that they get called when activity
happens.

Cheers, Tridge