On Fri, Jul 31, 2015 at 3:08 PM, <josh@xxxxxxxxxxxxxxxx> wrote: > On Fri, Jul 31, 2015 at 02:19:29PM -0700, Andy Lutomirski wrote: >> On Fri, Jul 31, 2015 at 1:59 PM, <josh@xxxxxxxxxxxxxxxx> wrote: >> > Agreed. I think the proposal above would be a net improvement, but >> > ideally you'd want something that's annotated and generates automatic >> > marshalling code. >> > >> >> I assume this is idle musing. If, however, we were to actually do >> this, I'd suggest we seriously consider speaking the Cap'n Proto >> serialization format. It's quite nice, it encodes and decodes *very* >> quickly and, unlike TLV schemes, you don't have to read it in order, >> making the read-side code less awkward. > > That seems like *massive* overkill for a kernel<->userspace syscall > interface. I was more thinking about having a few standardized marshal > types, and incrementally adding more when more patterns show up. For a > first pass, just automatically running copy_from_user and > copy_param_struct on appropriate sets of __user parameters identified as > such in a structured text file seems quite sufficient. (Plus > automatically generating syscalls.h from that.) If a param struct does the trick, then I agree. It's when you start having lists and other variable-size stuff that it gets messier. For reference, my Cap'n Proto parser (just the basic structure of messages, not the actual schema bits, although the latter is more or less just some structs) is about 300 lines of code. It's arguably simpler than nlattr, once you throw nesting in. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
