On Mon, Oct 17, 2022 at 06:57:13PM +0000, Edgecombe, Rick P wrote: > Hmm yea. Another reason the actual define is passed in is that the > macro want's to stringify the XFEATURE define in order to generate the > message like this: > XFEATURE_YMM: struct is 123 bytes, cpu state is 456 bytes > > The exact format of the message is probably not too critical though. If > instead it used xfeature_names[], it could be: > [AVX registers]: struct is 123 bytes, cpu state is 456 bytes Bah, "registers", that made me look at the thing. Yeah, not sure if all those "registers" strings even matter there. [AVX]: struct is 123 bytes, cpu state is 456 bytes looks good enough to me too. But WTH do I know. > The full block looks like (like you had): > switch (nr) { > case XFEATURE_YMM: return XCHECK_SZ(sz, nr, struct ymmh_struct); > case XFEATURE_BNDREGS: return XCHECK_SZ(sz, nr, struct > mpx_bndreg_state); > case XFEATURE_BNDCSR: return XCHECK_SZ(sz, nr, struct > mpx_bndcsr_state); > case XFEATURE_OPMASK: return XCHECK_SZ(sz, nr, struct > avx_512_opmask_state); > case XFEATURE_ZMM_Hi256: return XCHECK_SZ(sz, nr, struct > avx_512_zmm_uppers_state); > case XFEATURE_Hi16_ZMM: return XCHECK_SZ(sz, nr, struct > avx_512_hi16_state); > case XFEATURE_PKRU: return XCHECK_SZ(sz, nr, struct pkru_state); > case XFEATURE_PASID: return XCHECK_SZ(sz, nr, struct > ia32_pasid_state); > case XFEATURE_XTILE_CFG: return XCHECK_SZ(sz, nr, struct xtile_cfg); > case XFEATURE_CET_USER: return XCHECK_SZ(sz, nr, struct > cet_user_state); > case XFEATURE_XTILE_DATA: check_xtile_data_against_struct(sz); return > true; > default: > WARN_ONCE(1, "no structure for xstate: %d\n", nr); > XSTATE_WARN_ON(1); > return false; > } > > I like how it fits the XFEATURE_XTILE_DATA check in with the rest. Yap, nice and straight-forward pattern. :) Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette