lkml.org 
[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.151 / U:1.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site