thank you very much for checking it. Since Ben asked for waiting his
patch you can reject may patch, that's really fine with me as far as it
doesn't take months for his patch to showup. my patch is in perfect sync
with his latest code on the web.
as said I never claimed current API is stupid as Christph understood, I
said I'd preferred a sys_aio_read/write/fsync etc... but I could live
fine with sys_io_submit too, it wasn't too bad enough to make me rewrite
it.
With my patch I mainly wanted to raise eyes on this issue so we can
hopefully get an API registered in a few weeks in mainline. I'm
completely flexbile to rewrite the API too if anybody find good reasons
for it (or if you say, sys_io_submit is too ugly please change to
sys_aio_read/write/etc..).
As Ben said the API is the only thing that is been mostly stable so far,
this is one more reason I felt this is the right way to proceed instead
of building the dynamic syscall slowdown overhead layer that as best
(unsure for sys_io_sumbit 250) is forward binary compatible with 2.5 by
pure luck.
thanks,
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/