lkml.org 
[lkml]   [1998]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Writing to CMOS RAM
Meelis Roos wrote:
>
> tzdcu> 2) I'm not sure how to read and set the checksum so I just don't do it
> tzdcu> which obviously gives errros on reboot or waking from hiberbate.
> tzdcu> The CMOS RAM I am wrting to starts at the bytes which are offset
> tzdcu> 50 above the RTC RAM ie. where nvram.c stops.
>
> If the checksum algorithm is unified (is it?), maybe we should have an automatic
> checksum calculating in nvram driver (maybe some ioctl).
> It could (maybe even automatically) update the checksum if a byte is changed
> that is not in the time area and is not the checksum itself.
>
> Optinions?

I would rather have the errors on reboot for several reasons:

1) Different CMOSes may store checksums differently or in different
places. A checksum stored where a checksum doesn't belong could wipe out
another important section of data. And do we really want to bog down the
driver with a table of known CMOSes that we would have to keep updated
constantly? Probably not.

2) If the CMOS is edited by someone that shouldn't edit it, maybe this
would give us some sort of warning. We're talking hugely important
system stuff, here. You don't necessarily want to make it completely
convient for editing.

And finally, I would say that editing of the CMOS should probably be
done via a userspace interface to the driver that understands the
checksumming properly. That would keep that code out of the kernel and
you could still be able to edit to your heart's content whatever you
wanted.

Joe Pranevich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.057 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site