ahem. all new systems are going to have 128 byte NVRAMs anyway, so you
could basically keep a list of systems that have 64 bytes only. Why
Riley's solution is bad should be pretty obvious.
> > Is there any reason that wouldn't be the case ?
> I quote from the `man 3 sleep` manpage...
You want to run this code out of userspace ? Remember the address register
is write-only and there is no way to serialize access to it out of userspace
(cli() will work after iopl(3), but is not what you want on SMP systems).
> 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.
and you may not set the RTC in between.
> 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.
ditto.
> 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...
If you want to go into strange RTC chips, there's lots more for you:
> > 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
yes. I'd propose to do the sizing indepent of the kernel too, using either
module or command line parameters.
-
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/