On Fri, Jul 31, 2015 at 03:54:56PM -0700, Andy Lutomirski wrote: > 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. Sure, agreed. But I really hope we don't create new kernel ABIs that involve constructs like that. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
