>>>>> 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.
> Rather than go by the manufacturer, woudln't you be better off
> identifying the BIOS ? (as that is what is primarily using the
> nvram).
Whilst one will probably need to identify the BIOS to determine
precicely how the CMOS is being used, one also needs to remember that
MOST of the BIOS's in use are generic ones that can be used with both
64 byte and 128 byte CMOS chips.
>> 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!!!
> Agreed. Which is why I mentioned in an earlier mail that it
> doesn't belong in kernel space. To reiterate: Set the amount of
> exported data from /dev/nvram to the size of the biggest nvram
> that's known. Let applications that use it do the sizing.
Personally, I'd see this as being along the lines of /etc/localtime
and the timezone stuff - have an intelligent default setting in the
kernel, and a separate userland utility that can change the default.
My choice would be to have the kernel part thereof split in two,
using something along the lines of the following...
1. Do as little other kernel initialisation as possible. Only
the stuff that HAS to be done before the RTC can be touched
and the system clock initialised should be done at this
stage of the proceedings.
2. Read the RTC and initialise the system clock from it. In
the process, store the current value of the CMOS RAM at the
address offset corresponding to the mirrored RTC seconds
register.
3. Initialise EVERYTHING that hasn't already been initialised.
This should guarantee that the RTC seconds register has
been incremented at least once, which is the only guarantee
that is required.
4. As the final step in initialising the kernel, reread the
said CMOS RAM location. If it has changed, assume the CMOS
has 50 bytes of RAM available, otherwise assume that it
has 114 bytes of RAM available.
5. Start running the /etc/rc.d/rc (or whatever) scripts, to
start up the various userspace daemons and what-have-you.
Comments?
>>> You want to run this code out of userspace ?
>> Who said anything about using userspace?
> Me probably.
Not about that part of the proceedings, you didn't. I agree with you
that the code to determine exactly how the CMOS is mapped into values
on a given system needs to be in userspace, but the code to actually
locate, read and write it needs to be in the kernel itself.
>>> 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.
> If the algorithm Riley presented isn't possible from userspace,
> then either use the table approach, or (yeuch: a kernel space
> function addressable from userspace, via a function call or
> whatever)
The original algorithm that I presented IS possible from userspace,
despite certain pretences to the contrary, but it needs a bit more
work than I've given it to date to polish it up somewhat...
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/