Hi Riley,
> > Why Riley's solution is bad should be pretty obvious.
>
>I'm still waiting to hear a valid reason why it might be bad...
ok, here is what I think are the reasons:
it's slow.
it's specific to PC-style RTCs in that it requires their wraparound and the
seconds register at a certain location (so for example several separate chunks
of NVRAM would be hard to integrate).
it requires rewriting the existing nvram driver(s ?)
> >>> 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?
last I looked you would not normally use sleep() in the kernel.
> 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
If you have a guaranteed wrapping behaviour, you can get all the (1<<n)+RTC_SECONDS
values at one time, making the routine take one second regardless of the NVRAM's
size.
> point out the problems that need to be considered when doing anything
> like that, as they are best summarised by the text therein.
You'd avoid the rather ugly assumption sleep(1) always makes your secound counter
increment while just looping until its value changes. That way you could get your
routine to take .5 seconds on average.
>>> 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.
It means you may not take a timer interrupt while you are waiting, which is not
exactly what I would call 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.
I'm really waiting for your timer-interrupt-less kernel to run this code (the
chance it would not work is very slow, granted).
> >> 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.
I am sorry, I just wanted to say I really don't know what undocumented
weirdnesses are in all the RTC chips around (and that I don't want to),
not that I actually know of any specific problems.
Philipp Rumpf
-
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/