Re: Getting ready for IO extensions, v3

[Zach Brown <zab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Fri, Sep 19, 2014 at 05:46:34PM -0700, Darrick J. Wong wrote:
> Hi everyone,
> 
> I've been working (albeit slowly) on the userspace IO extension interface that
> I talked about last April[1].  The mechanism of attaching various attributes
> (which so far have been mandatory ones) to IO requests has been messy, since it
> requires me to design an interface for both the extensions I have in mind as
> well as a generic way to pass extensions into the kernel from userland.
> 
> Is this the appropriate forum to talk about API design in Linux?  It seems that
> way to me based on the list archives, but then I'm new at this, and would like
> to discuss the design before sending full patches (again).
> 
> So far I've defined this structure:
> 
> /* IO extension flags */
> #define IO_EXT_PI	(1)	/* protection info (checksums, etc) */
> #define IO_EXT_REPLICA	(0x2)	/* replica */
> #define IO_EXT_ALL	(IO_EXT_PI | IO_EXT_REPLICA)

Do we have more examples?  It's hard to make a strong case for the need
for variadic io syscalls with only a handful of optional arguments.

Completion timestamps?  priorities?  cgroup annotation?  (Haha, how
about a flag for a "trim" IO instead of having to do a stupid sync
ioctl).  I suppose the leading question is: what can the bio interface
do that userspace can't?

> The glaring downsides of this approach of course is that we waste memory on
> fields that might not be turned on, we have to find a sane way to handle the
> ie_has flags, and fields cannot be removed from the structure.  I don't know of
> a good way to design around those problems without greatly increasing the
> complexity of the data structure (a generic dictionary would work but ye gods
> that's horrifying), so I was wondering if any of you could suggest something
> better?

Maybe it'd just be easier to punt and re-use one of the N type/payload
interfaces.  sendmsg() and netlink are the big ones, right?  I think the
important thing is to translate them to internal kernel interfaces as
high up as possible so that the optional arg parsing is not pushed down
the stack.
 
- z