On Tue, May 11, 2010 at 12:14:47PM +0900, Paul Mundt wrote: > On Mon, May 10, 2010 at 03:55:49PM +0300, Eduardo Valentin wrote: > > On Mon, May 10, 2010 at 02:39:02PM +0200, ext Paul Mundt wrote: > > > Note that in the cpuinfo case there is often special handling for the > > > single (or boot CPU) case, such as printing out a descriptor for the > > > machine type and so on. You might be better off just extending cpuinfo > > > rather than introducing another /proc abstraction, presumably your > > > socinfo string will be fixed regardless of whether it's SMP or not. > > > > Yeah, I wouldn't expect it to change if it SMP or not. It should be fixed. > > Previous version of this change was actually extending ARM cpuinfo. The previous > > thread starts here: > > http://marc.info/?l=linux-omap&m=127304890312365&w=2 > > > > But, the point of moving that to specific file was that soc info is not really cpu info. > > > It's up to you of course, but adding an extra file because of SoC/CPU > ambiguity seems pretty ugly. Almost all architectures already include > machine type descriptors in their cpuinfo output (as ARM does also) and > if you can justify that then certainly adding in some SoC-specific bits > isn't exactly much of a stretch. > > These days you should have a pretty strong justification for adding new > procfs files, and this is certainly not one of them. I disagree. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
