lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZTqSqXfx9jlqvOuj@nanopsycho> Date: Thu, 26 Oct 2023 18:24:09 +0200 From: Jiri Pirko <jiri@...nulli.us> To: Jakub Kicinski <kuba@...nel.org> Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net, edumazet@...gle.com Subject: Re: [patch net-next v3] tools: ynl: introduce option to process unknown attributes or types Thu, Oct 26, 2023 at 04:46:38PM CEST, kuba@...nel.org wrote: >On Thu, 26 Oct 2023 07:41:20 -0700 Jakub Kicinski wrote: >> > What is "type" and "len" good for here? >> >> I already gave you a longer explanation, if you don't like the >> duplication, how about you stop keying them on a (stringified?!) id. > >Let's step back, why do you needs this? >Is what you're trying to decode inherently un-typed? >Or is it truly just for ease of writing specs for old families? When running this with newer kernel which supports unknown attr would be another usecase, yes. Better to print out known attr then keyerror.
Powered by blists - more mailing lists