Re: Is sysfs the right place to get cache and CPU topology info?

[Paul Mackerras]

Andrew Morton writes:

> Those are dopey weasel words and they should be removed.

Thanks.  That is my opinion too.

> If we put stuff in sysfs then people WILL use it and we WILL need to
> support it for ever.  Pointing at some document and saying "call my
> lawyer" just won't cut it.
> 
> sysfs is part of the kernel ABI.  We should design our interfaces there
> as carefully as we design any others.
> 
> > They read that to mean that sysfs is not a suitable interface for them
> > to use to get information about the system.  In particular they read
> > that to mean that if they do code their library to read sysfs, it will
> > change in the future in such a way as to break their code.
> > 
> > In other words, they see sysfs as being completely useless for them
> > because they can't depend on it as a stable interface.  Which is
> > reasonable given the quoted paragraph, but on the other hand, I don't
> > believe we break userspace interfaces as blithely as that paragraph
> > suggests.
> 
> Well it's up to them - they own the files.  If they later change them
> and break their own interfaces (and presumably their own applications),
> well, perhaps they have chosen an inappropriate career?

We have too many "they"s, perhaps.  I meant that these developers (of
an HPC library that wants to know about cpu caches and topology) see
sysfs as being completely useless as a source of information because
they expect random kernel developers to keep changing it in
incompatible ways.  So "they" (library developers) don't own the files
- they're not kernel developers at all.

> > So which is it?  Can they rely on the CPU cache and topology
> > information under /sys/devices/system/cpu/cpu*, and rely on having
> > that information there essentially forever?  Or are they correct in
> > saying sysfs is useless and we need to find some other way to expose
> > the cache and topology information?
> 
> Use sysfs.  Choose a representation which is maitainable in a
> backward-compatible fashion for all time.  Maintain it.

Thanks. :)

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