> >> Time should be an integer, not a struct. It ought to fit into a
> >> register on a 64-bit machine. If an API needs a struct, let libc
> >> convert as needed. The kernel should use a fast & simple format.
> >> (that is, a 64-bit integer type should last past 2038)
> >>
> >> Considering formats already in common use, we could count from 1601
> >> in units of 100 ns. That might seem odd, but 1601 is the last 400-year
> >> mark on the modern calendar.
> >
> > I will not do it, but you are invited to do that.
>
> I'd love to, but you are the time expert. Currently the kernel just
I wouldn't say that. ^^^^^^^^^^^
> uses a long jiffies counter, right? From your post, it seems that you
> want to change that nice fast counter into a struct.
(CC'd linux-kernel)
<clarification>
No, "jiffies will still be the same size and granularity (10ms on
i386). This is the low-level time in the kernel. I'm dealing with
high-level (user visible) time. Interestingly, user-visible time can
have a higher accuracy than the kernel low-level time, because we
interpolate with fast timeoffsets between interrupts. Currently up to
1 microsecond, mybe soon up to 1nanosecond (where hardware permits).
</clarification>
>
> >> Call it linux_time_value() just to remind everyone that the
> >> standard API is implemented in libc.
> >
> > I also don't want to reinvent the C library.
>
> I'm quite sure a libc hacker would quickly add the needed code.
> Please don't assume that libc makes raw kernel calls without any
> argument conversion. I'd like to see the slow stuff (like structs)
> stay out of the kernel.
BTW: What is the advantage to set the kernel time back to 1600? (It's
not for Windows/NT compatibility, is it?)
Regards,
Ulrich
-
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/