>>> 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 ?
I quote from the `man 3 sleep` manpage...
Q> DESCRIPTION
Q> sleep() makes the current process sleep until seconds
Q> seconds have elapsed or a signal arrives which is not
Q> ignored.
Q>
Q> RETURN VALUE
Q> Zero if the requested time has elapsed, or the number
Q> of seconds left to sleep.
Hopefully, signals won't mess things up, but that has to be accounted
for. There's also the fact that if the system clock ticks over
slightly faster than the RTC does, it's possible for the two
measurements to occur without the RTC seconds counter ticking over.
Balanced against that it the fact that this routine will get run
during kernel boot, and as written, it guarantees that it will take 1
second to pass through the loop every time, with the following timings
for the various detected sizes of CMOS chip...
Bytes Seconds
~~~~~~ ~~~~~~~
64 1
128 2
256 3
512 4
1,024 5
2,048 6
4,096 7
8,192 8
16,384 9
32,768 10
...and when one is waiting for the system to boot, even a single
second can seem like a very long time!!! Basically, I would see this
being dealt with in one of two ways:
A. Have the kernel perform the various parts of this
test at different points, with at least a second's
worth of other initialisations between each one. I
would see this as being VERY difficult to guarantee
as being done correctly since it would depend on
the speed of the processor as to how much needs to
be done between each check.
B. Have the kernel fork a separate thread that did the
measurement and set a static variable appropriately,
then exits, with the main kernel spending the time
starting up various other drivers, and at the end of
the kernel's initialisation, it makes use of the
resultant value to initialise /dev/nvram as needed.
There's also a third assumption that I overlooked when typing that in,
but it shouldn't be important...
3. All valid locations in the chip's addressing space that
are not occupied by RTC registers are occupied by CMOS
RAM locations that are distinct from each other.
I'm not aware of any chip where that isn't the case, but that doesn't
say that there isn't one...
> 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.
It might easily be a better idea, but there would probably need to be
some sort of default configuration as well.
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/