Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to exportOMAP data

[Andrew Morton]

On Tue, 11 May 2010 17:15:28 +0300
Eduardo Valentin <eduardo.valentin@xxxxxxxxx> wrote:

> Here is the version 5 of the change to export OMAP data to userspace
> (name, revision, id code, production id and die id).
> 
> Basically, this version is still attempting to create a new file under /proc.
> It is the /proc/socinfo, which should be used to export bits which are SoC specific
> (not CPU related, nor machine related).
> 
> So, differences between previous version are:
> - merged patch 02/04 with 03/04 to avoid compilation breakages.
> - simplified the seq_file usage by using the single_open and single_release functions
> - exported a function to register a seq_operation .show callback
> - adapted the changes accordingly
> 
> As usual, comments are welcome.

This changelog would be rather more useful if it was to show us some
sample output from /proc/socinfo, perhaps accompanied with an
explanation for people who aren't familar with this area of the kernel.

I'd have thought that sysfs was an appropriate place for this info. 
Perhaps under /sys/devices/platform?  Or /sys/devices/system?  Peter's
original patch didn't tell us where in the hierarchy the file was
placed, nor why it was placed there, not what its contents look like. 
But crappy changelogs are the norm :(

The objections stated in this email:
http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg17630.html
appear to still apply to this version of the patches?

Kevin didn't explain why he said "Please export these via debugfs". 
Tony didn't clearly explain why he said "I don't think we want to
export unique chip identifiers by default".



So apart from having certain opinions regarding communication skills
and wondering why people cc me on stuff without vaguely providing
enough info for me to understand what they're thinking, I don't know
what to make of it all :(
--
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/