Messages in this thread | | | Date | Wed, 11 Aug 2004 16:42:45 -0700 | From | Deepak Saxena <> | Subject | Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs |
| |
On Aug 12 2004, at 00:13, Dave Jones was caught saying: > On Wed, Aug 11, 2004 at 03:41:17PM -0700, Deepak Saxena wrote: > > > - Do we want to standardize on a set of attributes that all CPUs > > must provide to sysfs? bogomips, L1 cache size/type/sets/assoc (when > > available), L2 cache (L3..L4), etc? > > For x86 at least, this can be entirely decoded in userspace using > the /dev/cpu/x/cpuid interface. See x86info for example of this. > > > - Instead of dumping the "flags" field, should we just dump cpu > > registers as hex strings and let the user decode (as the comment > > for the x86_cap_flags implies. > > ditto.
OK, just saw that code now and my reponse is to remove that interface in the long-term and move cpuid into sysfs (and not export all the cache info separately). In theory we don't even need the xxx_bug fields as those can be determined from looking at CPU binary data.
> As these require arch specific parsers anyway, I don't think it makes > too much sense making a kernel abstraction trying to make them all > look 'the same', and if it can be done in userspace, why bother ?
If it is all done in userspace, then just having the raw binary data available via sysfs w/o kernel parsing is probably best. The question I have is are there any cross-platform userland tools/apps that just want to know things like cache-size w/o worrying about CPU specifics? Even if they do, I suppose they can be fixed to read that information from a binary blob and parse it dependent on the arch. ARM (other arch I really care about) could just output all the various ID registers into a binary blob and I am sure the same can be done for the other arches.
> The only other concern I have is the further expansion of sysfs with > no particular gain over what we currently have. The sysfs variant > *will* use more unreclaimable RAM than the proc version.
Agreed, but that hasn't kept other data such as PCI and partition information from moving into sysfs.
> /proc/cpuinfo has done well enough for us for quite a number of years > now, what makes it so urgent to kill it now that sysfs is the > virtual-fs-de-jour ?
Consitency in userspace interface. My understanding is that goal is to make /proc slowly return to it's original purpose (process-information) and move other data out into sysfs.
~Deepak
-- Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/
"Unlike me, many of you have accepted the situation of your imprisonment and will die here like rotten cabbages." - Number 6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |