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)
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
On Mon, May 10, 2010 at 05:22:48PM +0300, Eduardo Valentin wrote:
> On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> > You'll still need the show function, but all of the rest of this is just
> > duplicating what single_open() already does. If the socinfo string is
> > static you m
On Mon, May 10, 2010 at 03:08:09PM +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
I'm not aware of the module parameter stuff.. but the leak might be other thing
than kstrdup?
yeah, I was following the code and the problem is how the kernel handles
charp module parameters
--
balbi
Defec
Hello again,
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
> > +#include
> > +#include
> > +#include
> > +
> > +extern const struct seq_operations socinfo_op;
>
> This doesn't look pro
On Mon, May 10, 2010 at 02:54:40PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
> On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
> >You'll still need the show function, but all of the rest of this is just
> >duplicating what single_open() already does. If the socinfo string is
> >
On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
You'll still need the show function, but all of the rest of this is just
duplicating what single_open() already does. If the socinfo string is
static you may also want to rework this a bit so you can just stash the
string in the proc
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:
> > > > + */
> > > > +#incl
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
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +ext
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
> > +#include
> > +#include
> > +#include
> > +
> > +extern const struct seq_operations socinfo_op;
>
> This doesn't look promising..
Righ
On Mon, May 10, 2010 at 01:37:34PM +0300, Eduardo Valentin wrote:
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +extern const struct seq_operations socinfo_op;
This doesn't look promising..
> +static int socinfo_open(struct inode *inode, struct file *file)
> +{
> + return s
From: Eduardo Valentin
This patch introduce the /proc/socinfo node. Its purpose is to
export System on Chip information and specific bits.
The way it is done is basically same structure which is used to build
/proc/cpuinfo. Thus, it relies on the existence of socinfo_op seq_operation
structure.
12 matches
Mail list logo
