Laurent Pinchart wrote: >> That change causes a lot of clashes in naming since the equivalent >> kernel structure is there as well. Those could have _k postfix, for >> example, to differentiate them from user space names. I don't really >> have a good suggestion how they should be called. > > Maybe media_k_* ? I'm not very happy with that name either though.
Sounds better to me. >>> +- struct media_user_pad >>> + >>> +__u32 entity ID of the entity this pad belongs to. >>> +__8 index 0-based pad index. >> >> It's possible that 8 bits is enough (I think Hans commented this >> already). The compiler will use 4 bytes in any case and I think it's a >> good practice not to create holes in the structures, especially not to >> the interface ones. > > The direction could become a 8-bit integer, and a 16-bit > attributes/properties > bitfield would be added to fill the hole (it would be used to store pad > properties such as a busy flag). I'd rather make that field 32-bits wide > instead of 16 though. I guess you could put more reserved fields to these small holes. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
