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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
