Re: [PATCH RFC 04/20] Documentation: ctlv: Add userspace ABI

[Jonathan Cameron]

> >>``reply_len`` is never
> >> +overwritten; the length written is the reply root's ``len``. The pointers are
> >> +fixed-width so a 32-bit and a 64-bit process pass the same structure, and in
> >> +place of a size field the ioctl number encodes the size and ``reserved``, which
> >> +must be zero, covers compatible growth.
> >> +
> >> +Every action and query carries a physical request root, including an empty
> >> +request. ``request_len`` is therefore at least one attr header and at most the
> >> +1 MiB transport limit.  
> >
> >Why this particular limit?  Any thought to making that discoverable rather
> >than fixed? (with a minimum to allow the operation for the length to be discovered).  
> 
> OPS_DUMP exposes max size per op already. This limit serves different
> purpose. It is a safeguard againt insane family yaml author. If he would
> try to fit in ridiculously long binary attr, it would provide a clue to
> use blob attr instead. I think that 1M is too big. I would perhaps go
> with 64k initially. As it is kernel internal limit, could be changed in
> any time. Makes sense?

Yes. Small is better as as starting point I think. 64K should be enough
for anyone, right?

> 
> 
> >
> >Maybe it is better to just have fixed size.  I wonder if ultimately we
> >may end up with cases where the tlv is just passed on to firmware / device
> >(because it is nice and convenient!) and having to split or marshall
> >multiple messages would be a pain.  
> 
> hmm. tlvs passed to device would work, you would just have to take care
> of the blobs inside.

You'll know you succeeded when someone decides the device should
do the work ;)  Of course that's also the day when design decisions
are stuck even more in stone than they are for kernel /userspace ABI.


Thanks,

Jonathan