Re: Wrong number of core_siblings in sysfs for Athlon64 X2

[Zan Lynx <zlynx@acm.org>]

On Fri, 2006-02-17 at 03:18 +0100, Andi Kleen wrote:
> On Friday 17 February 2006 03:10, Zan Lynx wrote:
> 
> > It seems to me that this could be confusing for a lot of people who are
> > casually browsing through sysfs.  Why not name core_siblings something
> > like core_sibling_bitmap? 
> 
> Because it's already a fixed ABI that is put in stone.

Hardly "fixed in stone."  I checked before making the suggestion to
change it, the topology sysfs entries are only in 2.6.16-rc kernels, so
they've never been released in an official mainline kernel.  Fixed in
clay that hasn't been fired yet, perhaps.  Maybe by -rc3 it's already
baking in the kiln, but its still changeable.

> The only way to do what you want would be to add a new field
> and keep the old one alone, but frankly your rationale for 
> it ("could be confusing to someone") doesn't seem convincing enough 
> for such a thing.  Especially since each sysfs field can
> cost considerable memory when a dentry and a inode have to be allocated
> for it.

Now is hardly the time to worry about efficiency in sysfs.  It's already
a maze of twisty symlinks.  And the whole rationale of sysfs is easy
shell-tool access to kernel data about the system.  

> I guess if you worry about such people a better way to help
> them would be to write them a frontend that displays
> the information in there in nice form.

Nice frontends processing efficient but hard to read data would be best
implemented in binary through netlink or system calls where there would
be no need to format to text, create an inode, then have userspace open
directories, follow links, open a file, read it, parse it BACK into
binary, etc.  

So obviously efficiency isn't a primary sysfs consideration.  That would
leave ... ease of use? :-)

Your two objections aren't convincing to me, but I don't suppose it
matters since I don't have a major interest in the topology code or how
it works.  So continue on!  It was only a helpful suggestion.
-- 
Zan Lynx <zlynx@acm.org>

Attachment: signature.asc
Description: This is a digitally signed message part