Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Dave Jones]

On Wed, Aug 11, 2004 at 04:42:45PM -0700, Deepak Saxena wrote:

 > > 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).

but why? it's totally pointless when the same info can be obtained
from userspace without the bloat.

 > In theory we don't even 
 > need the xxx_bug fields as those can be determined from looking
 > at CPU binary data.

not all of them you can't iirc.

 > > 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 raw binary is already available. in /dev/cpu/x/cpuid
I repeat, duplicating this in sysfs is utterly pointless other than
to bloat the kernels runtime memory usage.

 > > 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.

So because one subsystem decides to do it, every other should follow
lemming-like ?
 
 > > /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.

sorry, but I think that argument is total crap.  Any userspace tool needing
this info will still need to support the /dev/cpu/ interfaces if they want to
also run on 2.2 / 2.4 kernels.  Likewise, anything using /proc/cpuinfo.
Ripping this out does nothing useful that I see other than cause headache
for userspace by having yet another interface to support.

 > 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.  

I don't think thats a realistic goal. It'll take years just to migrate the
in-kernel stuff, and there's god alone knows how much out-of-tree code doing
the same, plus the add-ons from various vendor kernels etc so I doubt it'll
ever be the process-only utopia you envision.

Changing userspace interfaces on a whim just causes pain for those
that use them, especially when there is nothing wrong with the existing
interfaces.

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/