>>> Rather than go by the manufacturer, woudln't you be better
>>> off identifying the BIOS ? (as that is what is primarily
>>> using the nvram).
>> I think we all would be better off not wasting our time with
>> this...
> I personally have no desire to write a program to interpret
> these extended bytes, but should someone have that desire, the
> need to extend the amount of bytes exported by /dev/nvram is
> there. I see no reason why the limit shouldn't be increased.
The main purpose to the /dev/nvram driver as I see it is to be able to
get hold of system configuration information without rebooting the
system. For this purpose, all that's needed is for /dev/nvram to be a
device that emulates /dev/null and /dev/zero when written to.
In fact, seen from that viewpoint, /dev/nvram would be much better
placed as a directory /proc/nvram with the various fields expressed as
files in that directory. Make /proc/nvram owned by 0.0 with mode 0500
and the files therein ditto, and it's as secure as it needs to be.
> Unless there is some flaky nvram that does strange things when
> you try to read locations that it doesn't have, but I know of no
> such device.
I've never met any.
> btw, Is there a current maintainer of the nvram driver?
No idea, but I would presume so.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/