Proc stuff

Proc stuff

[Ian S. Nelson]

I need some extra bits added to the proc/mtd.  For the product I'm
building we want to have things from the flash registers like the Device
ID and "AMD flash"

Anything else anyone wants while I'm in there?  Also, I was thinking I'd
just add a few extra columns to the /proc/mtd file if that's distasteful
I could create a /proc/mtd directory and put a few different "files" in
there.  Any comments before I start hacking?

thanks,
Ian Nelson

PS, it's bloody fast on my system too.  I have this hilo burner that
takes 20+ minutes to burn a 2Mbyte flash while MTD does it in closer to
20 seconds.  Very very cool.



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Proc stuff

[David Woodhouse]

ian.nelson@echostar.com said:
> I need some extra bits added to the proc/mtd.  For the product I'm
> building we want to have things from the flash registers like the
> Device ID and "AMD flash"

Those aren't particularly generic bits of information - why do you think
they should be present at that level? That kind of detail is reported in the
boot messages, not in /proc/mtd. Does your eth0 device provide a way to find
out which chipset it is?

Perhaps we could make the CFI drivers put slightly more informative 
information in the 'name' field, but that doesn't work nicely if you have 
partitions which override the original name. 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Proc stuff

[Johan Adolfsson]

I guess we would like that kind of information available somewhere
as well. Either through /proc or through an ioctl().

We (Axis) have an ioctl() to get that info with our own flash driver
and JFFS available on developer.axis.com (not using mtd).
It is typically used to verify that a certain type of chip is mounted
during production test where boot messages are not even enabled
and not a nice way to get the information for that purpose anyway.

Since mtd is not flash specific, perhaps a generic info string
about the device media could be added?

/Johan


----- Original Message -----
From: David Woodhouse <dwmw2@infradead.org>
To: <ian.nelson@echostar.com>
Cc: <mtd@infradead.org>
Sent: Thursday, April 05, 2001 14:47
Subject: Re: Proc stuff


>
> ian.nelson@echostar.com said:
> > I need some extra bits added to the proc/mtd.  For the product I'm
> > building we want to have things from the flash registers like the
> > Device ID and "AMD flash"
>
> Those aren't particularly generic bits of information - why do you think
> they should be present at that level? That kind of detail is reported in
the
> boot messages, not in /proc/mtd. Does your eth0 device provide a way to
find
> out which chipset it is?
>
> Perhaps we could make the CFI drivers put slightly more informative
> information in the 'name' field, but that doesn't work nicely if you have
> partitions which override the original name.
>
> --
> dwmw2
>
>
>
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
>



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Proc stuff

[David Woodhouse]

johan.adolfsson@axis.com said:
>  We (Axis) have an ioctl() to get that info with our own flash driver
> and JFFS available on developer.axis.com (not using mtd). It is
> typically used to verify that a certain type of chip is mounted during
> production test where boot messages are not even enabled and not a
> nice way to get the information for that purpose anyway.

> Since mtd is not flash specific, perhaps a generic info string about
> the device media could be added? 

That's what the 'name' field was intended for. The CFI and other probe 
functions already return the MTD device to the map driver so that 
partitioning and other stuff can be done. Setting an appropriate name which 
provides any board-specific information is entirely feasible.

Isn't that enough?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Proc stuff

[Ian S. Nelson]

David Woodhouse wrote:

> ian.nelson@echostar.com said:
> > I need some extra bits added to the proc/mtd.  For the product I'm
> > building we want to have things from the flash registers like the
> > Device ID and "AMD flash"
>
> Those aren't particularly generic bits of information - why do you think
> they should be present at that level? That kind of detail is reported in the
> boot messages, not in /proc/mtd. Does your eth0 device provide a way to find
> out which chipset it is?

Actually, it does now.    I thought about parsing the log or dmesg but we're
turning logging off in the product because it's unneeded disk I/O and disk I/O
is critical.  I was looking at the IDE directory under proc and there is an
entry for your southbridge/IDE controller and some other specific things so
that  I can dig around in /proc/ide and know exactly what drives and
IDE controllers I've got on the system.


> Perhaps we could make the CFI drivers put slightly more informative
> information in the 'name' field, but that doesn't work nicely if you have
> partitions which override the original name.

We could, I was just offering to try and do a complete job if someone else
wants or needs anything in there.  During our manufacturing test we need to
specifically identify each and every part of our hardware and so I've been
stuffing that into /proc.  I will do it that way for our particular kernel and
code but if I can write something that will be helpful to others I want to do
that.

Maybe the solution is to create a /proc/mtd directory and then have a few
different files in there which can either be generic or specific.  There are
other places in the kernel that do this so it's un unprecedented.  /proc is
nice and easy to read so you can build scripts and simple things to read it.
An ioctl could also work.

Ian



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Proc stuff

[David Woodhouse]

ian.nelson@echostar.com said:
>  Maybe the solution is to create a /proc/mtd directory and then have a
> few different files in there which can either be generic or specific.
> There are other places in the kernel that do this so it's un
> unprecedented.  /proc is nice and easy to read so you can build
> scripts and simple things to read it. An ioctl could also work. 

/proc is nicer, if we really have to do it. How about /proc/driver/mtd/$n,
each one containing something along the lines of...

name: "blah"
size: 0x1000000
erasesize: 0x10000

The standard lines can be provided by a generic function, and we add a
proc_filler method to the mtd_info stucture which overrides that to allow
you to do whatever else you want.

Actually, mtdfs is probably nicer than adding yet more cruft to /proc. 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Proc stuff

[Eric W. Biederman]

David Woodhouse <dwmw2@infradead.org> writes:

> ian.nelson@echostar.com said:
> >  Maybe the solution is to create a /proc/mtd directory and then have a
> > few different files in there which can either be generic or specific.
> > There are other places in the kernel that do this so it's un
> > unprecedented.  /proc is nice and easy to read so you can build
> > scripts and simple things to read it. An ioctl could also work. 
> 
> /proc is nicer, if we really have to do it. How about /proc/driver/mtd/$n,
> each one containing something along the lines of...
> 
> name: "blah"
> size: 0x1000000
> erasesize: 0x10000
> 
> The standard lines can be provided by a generic function, and we add a
> proc_filler method to the mtd_info stucture which overrides that to allow
> you to do whatever else you want.
> 
> Actually, mtdfs is probably nicer than adding yet more cruft to /proc. 

Espeically in the context of embedded systems where sometimes you want
the option to compile out as much as you can.  With /proc it is a
giant growing lump, with a mtdfs, you can include it if you need it.

Long term I think the tradeoff between a 256 line fstab for a million
in kernel filesystems you might need on a big server with everything,
versus 100+ mandatory kilobytes and growing for /proc is a good one.

Eric


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org