RE: PATCH: /dev/nvram cleanups.

Jones D (djones2@glam.ac.uk)
Thu, 29 Jul 1999 12:53:37 +0100

> > This just leaves the issue of sizing the nvram.
> > Maybe this can be determined by checking the BIOS
> > manufacturer & version. (Admittedly this could be a
> > large table, but this part is in userspace anyhow).
> > If the manufacturer or version are not supported, just
> > make the first 50 bytes available (as it is now),
> > otherwise size it accordingly from the lookup table.
>
> Alternatively, why not use the fact that the chips with only
> 0-63 as valid addresses effectively fold back 64-127 to 0-63
> to auto-detect that fact. Something like the following:
<SNIP>

Assuming that the algorithm you presented works on all the different
sizes (which I think it will), that's a much more elegant solution
than the lookup-table idea I presented, as it's zero maintainance.

> The above code makes the following assumptions:
> 2. The result of the sleep(1) call will always be sufficient
> for the second counter to tick over.

Is there any reason that wouldn't be the case ?

This whole nvram thing has got me thinking.
Would it be better if the fields in the /proc/nvram 'file' could be filled
in
by a userspace app on startup? This sort of thing could also be done for
quite
a few other things in /proc, saving a fair bit of space in the kernel.

regards,

Dave.

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