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
| ||
|
Date: Mon, 5 Oct 2020 17:27:17 -0700 From: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com> To: Borislav Petkov <bp@...en8.de> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, x86@...nel.org, Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, Tony Luck <tony.luck@...el.com>, Len Brown <len.brown@...el.com>, "Ravi V. Shankar" <ravi.v.shankar@...el.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/4] drivers core: Introduce CPU type sysfs interface On Sat, Oct 03, 2020 at 10:49:34AM +0200, Borislav Petkov wrote: > On Fri, Oct 02, 2020 at 06:17:41PM -0700, Ricardo Neri wrote: > > Patch 1 of the series proposes the generic interface, with hooks > > that architectures can override to suit their needs. The three patches > > patches implement such interface for x86 (as per request from Boris, > > I pulled patch 2 from a separate submission [1]). > > So I ask you to show me the whole thing, how this is supposed to be used > in a *real* use case and you're sending me a couple of patches which > report these heterogeneous or whatever they're gonna be called CPUs. > > Are you telling me that all this development effort was done so that > you can report heterogeneity in sysfs? Or you just had to come up with > *something*? > > Let me try again: please show me the *big* *picture* with all the code > how this is supposed to be used. In the patches I read a bunch of "may" > formulations of what is possible and what userspace could do and so on. > > Not that - show me the *full* and *real* use cases which you are > enabling and which justify all that churn. Instead of leaving it all to > userspace CPUID and the kernel not caring one bit. > > Does that make more sense? Yes Boris, thanks for the clarification. The proposed sysfs interface is one instance in which we use cpuinfo_x86.x86_cpu_type. I have other changes that use this new member. I will post them. > > > [1]. https://lkml.org/lkml/2020/10/2/1013 > > For supplying links, we use lore.kernel.org/r/<message-id> solely. > Please use that from now on. Sure Boris, I will use lore.kernel.org in the future. Thanks and BR, Ricardo
Powered by blists - more mailing lists