Proc stuff
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 [email protected]
Quoted 3 lines · [email protected] 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 [email protected]
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 <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Thursday, April 05, 2001 14:47
Subject: Re: Proc stuff
Quoted 8 lines
Quoted 3 lines · [email protected] 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
Quoted 1 line
boot messages, not in
/proc/mtd. Does your eth0 device provide a way to
find
Quoted 6 lines
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.
Quoted 8 lines
--
dwmw2To unsubscribe, send "unsubscribe mtd" to [email protected]
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 8 lines · [email protected] 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 [email protected]
Quoted 9 lines · David Woodhouse
Quoted 3 lines · [email protected] 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.
Quoted 3 lines
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 [email protected]
Quoted 5 lines · [email protected] said:
Maybe the solution is to create a
/proc/mtddirectory 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 [email protected]
Quoted 14 lines · David Woodhouse
Quoted 5 lines · [email protected] said:
Maybe the solution is to create a
/proc/mtddirectory 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
Quoted 5 lines
The standard lines can be provided by a generic function, and we add a
proc_fillermethod to themtd_infostucture 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 [email protected]