From: Greg KH <gregkh@linuxfoundation.org> To: Thomas Gleixner <tglx@linutronix.de> Cc: Thomas Renninger <trenn@suse.de>, linux-kernel@vger.kernel.org, Felix Schnizlein <fschnizlein@suse.de>, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, will.deacon@arm.com, x86@kernel.org, fschnitzlein@suse.de, Felix Schnizlein <fschnizlein@suse.com>, Thomas Renninger <trenn@suse.com> Subject: Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86 Date: Tue, 10 Dec 2019 21:53:48 +0100 [thread overview] Message-ID: <20191210205348.GA4080658@kroah.com> (raw) In-Reply-To: <87sglroqix.fsf@nanos.tec.linutronix.de> On Tue, Dec 10, 2019 at 09:48:54PM +0100, Thomas Gleixner wrote: > Greg KH <gregkh@linuxfoundation.org> writes: > > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote: > >> From: Felix Schnizlein <fschnizlein@suse.de> > >> ==> 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
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org> To: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org, Felix Schnizlein <fschnizlein@suse.de>, Felix Schnizlein <fschnizlein@suse.com>, x86@kernel.org, will.deacon@arm.com, linux@armlinux.org.uk, Thomas Renninger <trenn@suse.com>, linux-kernel@vger.kernel.org, fschnitzlein@suse.de, Thomas Renninger <trenn@suse.de>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86 Date: Tue, 10 Dec 2019 21:53:48 +0100 [thread overview] Message-ID: <20191210205348.GA4080658@kroah.com> (raw) In-Reply-To: <87sglroqix.fsf@nanos.tec.linutronix.de> On Tue, Dec 10, 2019 at 09:48:54PM +0100, Thomas Gleixner wrote: > Greg KH <gregkh@linuxfoundation.org> writes: > > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote: > >> From: Felix Schnizlein <fschnizlein@suse.de> > >> ==> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-10 20:53 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-06 16:24 [PATCH v5 0/3] sysfs: add sysfs based cpuinfo Thomas Renninger 2019-12-06 16:24 ` Thomas Renninger 2019-12-06 16:24 ` [PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework Thomas Renninger 2019-12-06 16:24 ` Thomas Renninger 2019-12-06 16:33 ` Greg KH 2019-12-06 16:33 ` Greg KH 2019-12-06 16:33 ` Greg KH 2019-12-06 16:56 ` Randy Dunlap 2019-12-06 16:56 ` Randy Dunlap 2019-12-06 16:56 ` Randy Dunlap 2019-12-06 16:24 ` [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86 Thomas Renninger 2019-12-06 16:24 ` Thomas Renninger 2019-12-06 16:36 ` Greg KH 2019-12-06 16:36 ` Greg KH 2019-12-10 20:48 ` Thomas Gleixner 2019-12-10 20:48 ` Thomas Gleixner 2019-12-10 20:53 ` Greg KH [this message] 2019-12-10 20:53 ` Greg KH 2019-12-11 10:42 ` Thomas Renninger 2019-12-11 10:42 ` Thomas Renninger 2019-12-11 13:56 ` Greg KH 2019-12-11 13:56 ` Greg KH 2019-12-11 14:12 ` Thomas Renninger 2019-12-11 14:12 ` Thomas Renninger 2019-12-11 14:26 ` Greg KH 2019-12-11 14:26 ` Greg KH 2019-12-11 14:52 ` Thomas Renninger 2019-12-11 14:52 ` Thomas Renninger 2019-12-11 14:57 ` Greg KH 2019-12-11 14:57 ` Greg KH 2019-12-06 16:24 ` [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64 Thomas Renninger 2019-12-06 16:24 ` Thomas Renninger 2019-12-06 16:37 ` Greg KH 2019-12-06 16:37 ` Greg KH 2019-12-09 10:31 ` Will Deacon 2019-12-09 10:31 ` Will Deacon 2019-12-09 11:28 ` Thomas Renninger 2019-12-09 11:28 ` Thomas Renninger 2019-12-09 17:38 ` Will Deacon 2019-12-09 17:38 ` Will Deacon 2019-12-10 13:33 ` Thomas Renninger 2019-12-10 13:33 ` Thomas Renninger 2019-12-10 14:47 ` Greg KH 2019-12-10 14:47 ` Greg KH 2019-12-10 16:24 ` Thomas Renninger 2019-12-10 16:24 ` Thomas Renninger 2019-12-06 16:58 ` [PATCH v5 0/3] sysfs: add sysfs based cpuinfo Mark Rutland 2019-12-06 16:58 ` Mark Rutland 2019-12-06 17:29 ` Thomas Renninger 2019-12-06 17:29 ` Thomas Renninger 2019-12-06 18:16 ` Mark Rutland 2019-12-06 18:16 ` Mark Rutland
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191210205348.GA4080658@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=fschnitzlein@suse.de \ --cc=fschnizlein@suse.com \ --cc=fschnizlein@suse.de \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=tglx@linutronix.de \ --cc=trenn@suse.com \ --cc=trenn@suse.de \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.