[lkml]   [1999]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: /dev/nvram cleanups.
Hi Philipp.

>>> 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:

> 1. it's slow.

Rephrase that - it needs polishing to speed it up. I can agree with
that - indeed, I said as much in an earlier post. As I also pointed
out at the same time, the code snippet was written to highlight the
method of auto-detecting how much CMOS in that chip, and not as an
example of speedy code.

Indeed, my experience has been that examples of speedy code usually
hide the method behind what they're trying to do behind all the fluff
needed to get the speed, so I would be VERY wary of a snippet that
claimed to do both...

> 2. 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).

As I see it, if there's more than one chunk of NVRAM, it's because
they are in separate chips, and each chip would need to be probed
separately, so that isn't an issue.

> 3. it requires rewriting the existing nvram driver(s ?)

It doesn't actually - all that changes is the amount of ram the
current nvram driver can refer to, and that is at worst a case of
changing what's currently a constant into a global variable. The
rest of the driver would stay as it is.

Remember, the current nvram driver just blindly assumes that only
50 bytes of CMOS RAM exist. With the auto-detection in place, it
would instead know the amount of RAM present, something which is
generally agreed to be a good thing, at least if the comments on this
list are any guide.

>>>>> 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.

For the purpose of an example designed to CLEARLY show the basic
method, the use of sleep(1) was ideal, but is should have been
read as "at this point, do whatever is appropriate until the second
counter has changed". Taken in that context, it says exactly what it
needed to, neither more nor less.

>> 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.

> If you have a guaranteed wrapping behaviour...

All the chips I have seen and used have that behaviour, mainly because
it's cheaper for the manufacturers to implement them that way. Because
of that, I would be highly surprised to see such change any time soon.

> can get all the (1<<n)+RTC_SECONDS values at one time,
> making the routine take one second regardless of the NVRAM's
> size.

That comes under the heading of being an optimisation to the algorithm
rather than being a separate algorithm. Remember, the snippet was
designed to show the method, not to be a world speed champion that hid
all the details of how it worked.

>> 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.

> 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.

Add in the optimisation you refer to above, and one can get the
routine to take 0.5 seconds TOTAL.

Alternatively, just put the two steps at opposite ends of the kernel's
internal initialisation procedure and have it effectively take 0 time
due to the fact that even on the fastest processor, the kernel takes
rather more than a second to initialise...

However, none of this makes the slightest change to the basic method.

>>>> 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.

Why does it mean that? The kernel's timer interrupt routine never
reads the RTC anyway - in fact, apart from setting the system clock
during the boot-up procedure, nothing in the kernel's boot process
touches the RTC or CMOS at all.

>>>> 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).

I'm still waiting for you to point out where in the timer interrupt
routine the RTC or CMOS is changed.

You're not by any chance getting confused with the system timer chip,
which generates the 100 Hz (1024 Hz on Alpha) timer tick interrupts,
are you? If so, that's a completely separate subsystem with no
connection to the RTC and CMOS.

>>>> 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.

In other words, you're just inventing problems so you can ask how we
deal with them !!!

For reference, I've spent the best part of the last DECADE working
with various RTC chips, and I have yet to come across one that the
above method would not handle. I've met the following variations:

1. External address pins or one or more internal address

2. RTC registers occupying from 8 to 16 addresses.

3. RTC registers only or with CMOS as well.

4. Where CMOS is present, RTC registers at the bottom or
top of the address map.

5. Where CMOS is present, from 16 to 1010 bytes of CMOS. It is
for this reason that I used a 16-bit value for the limit

I have not yet met any where the RTC chip includes CMOS in which there
were any non-register locations in the chip that were not valid CMOS
locations, but I would not be surprised to meet such a chip.

One final point: Certainly as far as ix86 systems are concerned, the
manufacturers will in general use chips that remain compatible with
those used on earlier systems, primarily because it's cheaper for them
to do so - if they start using non-standard chips, they have to go to
the expense of obtaining custom drivers for those chips as used in
their systems for the Windows family of operating systems, otherwise
their machines just won't sell. As a result, it is a reasonable
assumption to state that such will in fact happen.

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. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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