Native Linux AIO in Samba4

[tridge at samba.org]

Jeremy,

 > That's a problem in the Linux kernel - I'm hoping they'll
 > adapt glibc to hook the underlying interface into the POSIX api.

yes, that seems likely to happen at some stage.

 > > Regarding the epoll/aio kernel code that this relies on, there is some
 > > discussion of using a new events system in the kernel called kevents
 > > instead. The kevents API is certainly much cleaner (the aio/epoll
 > > integration is a pretty nasty hack in comparison!), but I don't know
 > > which will end up being the standard. Maybe we'll end up with both,
 > > in which case we'll support both in Samba4.
 > 
 > That's another reason I was waiting - I'm hoping one will win out
 > in the end and become "standard" on Linux.

With lib/events/ we're able to plug in different event systems quite
easily now. We've now got support for select, epoll, aio, liboop and
the gtk events system (which uses poll).

We've been waiting for these things to settle down for too long I
think. One of the reasons they don't settle down is that the kernel
developers don't see much demand for the new interfaces. They ask
"who's using them?". If we stay conservative and only use the ones
that are totally stable then by that act of waiting we are in fact
delaying the development.

I think that's why Linux AIO for a long time only supported O_DIRECT
files. It was the people using O_DIRECT that were demanding AIO (the
database people). Because we held back, we didn't end up with AIO that
was useful to us in the Linux kernel.

How about merging lib/events into Samba3? There is a cut-down version
there now, but if the full lib was merged and it was used instead of
select in the top level event loop in smbd that would gain us the
following:

 - you could easily add native Linux aio
 - it becomes easy to add fd and/or timed events locally in a
   subsystem of the code without changing the main loop
 - it is an essential step towards merging the main async libs from
   Samba4 (rpc, raw smb, nbt, ldap etc)
 - you can choose event backends at runtime

The main problem would be signals I think. I've completely avoided
signals in Samba4 (for all the usual reasons - signals are truly
horrible). Samba3 still relies on signals so we'd need a
event_add_signal() call which tries to make signals saner. It would
need a static signal->handler table as signals can't pass state
information portably.

Cheers, Tridge