On Fri, Aug 13, 2021 at 01:14:58PM +0300, Andy Shevchenko wrote: > > Andy, does this incremental diff restore your reviewed-by? The awkward > > piece of this for me is that it introduces a handful of unnecessary > > memory copies. See some of the new nsl_get_uuid() additions and the > > extra copy in nsl_uuid_equal() > > It does, thanks! As for the deeper discussion I think you need to talk to > Christoph. It was his idea to move uuid_t from UAPI to internal kernel type. > And I think it made and still makes sense to be that way. > > But if we have already users of uuid_t like you are doing here (without this > patch) then it will be fine I guess. Not my area to advise or decide.
I'm missing a lot of context here. But that whole uuid/guid thing is a little complex: - for userspace APIs and on-disk formats a uuid is nothing but a blob - userspace historically has its own library to deal with this (libuuid), which defines a uuid_t itself. So instead of trying to build abstractions that somehow word in diferent software ecosystems I think just treating it as the blob that it is for exchange makes life easіer for everyone. It also really makes definitions of on-disk structures more clear when using the raw bytes instead of a semi-opaque typedef.
