On Tue, Nov 10, 2020 at 09:07:16AM +0100, Peter Zijlstra wrote: > On Mon, Nov 09, 2020 at 10:53:54PM +0100, Jiri Olsa wrote: > > Adding support to carry build id data in mmap2 event. > > > > The build id data replaces maj/min/ino/ino_generation > > fields, whichc are also used to identify map's binary, > > so it's ok to replace them with build id data: > > > > union { > > struct { > > u32 maj; > > u32 min; > > u64 ino; > > u64 ino_generation; > > }; > > struct { > > u8 build_id[20]; > > u8 build_id_size; > > What's the purpose of a size field for a fixed size array? Also, I'd
at the moment there's SHA build id using 20 bytes and MD5 is using 16 bytes, so build_id_size tells which one is in I was considering adding another enum instead, but buildid is defined just by the size of the hash, so size seemed better.. if in future there's another type added and fits within 20 bytes we're ok, if it's bigger we're screwed anyway > flip the order of these fields, first have the size and then the array. ok jirka > > > u8 __reserved_1; > > u16 __reserved_2; > > }; > > }; > > > > Replaced maj/min/ino/ino_generation fields give us size > > of 24 bytes. We use 20 bytes for build id data, 1 byte > > for size and rest is unused. >