Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

From: Greg KH
Date: Tue Dec 10 2019 - 15:53:53 EST


On Tue, Dec 10, 2019 at 09:48:54PM +0100, Thomas Gleixner wrote:
> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> >> From: Felix Schnizlein <fschnizlein@xxxxxxx>
> >> ==> flags <==
> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip
> >
> > One file with all of that? We are going to run into problems
> > eventually, that should be split up.
> >
> > Just like bugs, that's going to just grow over time and eventually
> > overflow PAGE_SIZE :(
> >
> > Make this:
> > âââ flags
> > â âââ fpu
> > â âââ vme
> > ...
> >
> > Much simpler to parse, right?
>
> Well, I'm not really sure whether 100+ files are simpler to parse.
>
> Aside of that I really don't see the value for 100+ files per CPU which
> are just returning 1 or True or whatever as long as you are not
> suggesting to provide real feature files which have 0/1 or True/False
> content.
>
> But I still don't get the whole thing. The only "argument" I've seen so
> far is the 'proc moves to sys' mantra, but that does not make it any
> better.

That is not a valid mantra, as I tried to explain later in this thread.

I don't understand the need for this patchset either, all I was trying
to do was to at least make it sane from a sysfs-point-of-view if people
really wanted to do this type of thing.

> We won't get rid of /proc/cpuinfo for a very long time simply because
> too much userspace uses it. Introducing a mess in /sys/ in parallel just
> for following the mantra does not help much.

Again, invalid mantra, not a valid reason :)

I think this is a patchset in search of a problem, which is why it was
dropped all those years ago...

thanks,

greg k-h