Re: [PATCHv4 1/4] procfs: Introduce socinfo under /proc

[Eduardo Valentin]

On Mon, May 10, 2010 at 02:39:02PM +0200, ext Paul Mundt wrote:
> On Mon, May 10, 2010 at 03:35:14PM +0300, Eduardo Valentin wrote:
> > On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> > > On Mon, May 10, 2010 at 01:37:34PM +0300, Eduardo Valentin wrote:
> > > > + */
> > > > +#include <linux/fs.h>
> > > > +#include <linux/init.h>
> > > > +#include <linux/proc_fs.h>
> > > > +#include <linux/seq_file.h>
> > > > +
> > > > +extern const struct seq_operations socinfo_op;
> > > 
> > > This doesn't look promising..
> > 
> > Right.. as stated in patch description (maybe not that clear), this was
> > basically same thing which you see under fs/proc/cpuinfo.c
> > 
> The cpuinfo case is a bit more complex since you have actual real work to
> do in the ->start op and you will iterate over the ->show op for each
> CPU. In your socinfo case you're just following the single_xxx()
> semantics so using those helpers there simplifies things quite a bit.

Yeah,

> 
> Architectures that do not support SMP technically employ single_open()
> semantics, but the fs/proc/cpuinfo.c abstraction requires the
> architecture to provide seq ops regardless.

OK.

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


BR,

--
Eduardo Valentin
--
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/