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