>>> 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.
> 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.
When composing that list, start by listing the entire CURRENT Packard
Bell range. Certainly all the models I've checked have 64 byte NVRAM
chips on them.
OTOH, some people are so keen to bloat the kernel that they'll put
just about any kind of rubbish in it - or are you implying that the
list of systems with various CMOS sizes is going to be small!!!
> Why Riley's solution is bad should be pretty obvious.
I'm still waiting to hear a valid reason why it might be bad...
>>> 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 ?
Who said anything about using userspace?
Perhaps I can emphasise a point I believe I made in a previous post,
which is that the code snippet I wrote was to show the ALGORITHM that
I was suggesting be used. My quote from the sleep(3) manpage was to
point out the problems that need to be considered when doing anything
like that, as they are best summarised by the text therein.
> 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).
Since you're the one proposing a userspace solution, you'd better
propose a way round that...if you see it as a problem, that is.
>> 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.
Both true and irrelevant.
>> 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.
Again, 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:
Thanks for confirming my suspicion that suchlike chips do indeed
exist. That basically means that ANY auto-sizing algorithm needs to be
able to detect suchlike locations AFTER first detecting the chip's
address bus size.
>>> 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.
Don't expect to see it get in the kernel then - Linus has already
stated that requiring parameters for something the kernel should be
able to auto-detect is a no-no, and that definately applies here, at
least unless somebody can come up with a sensible reason why it can't
be done.
OTOH, you might get away with inserting a new config option in one of
the various config.in scripts, and require the user to select the
correct RTC chip at compile time...
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/