Re: module mess in -CURRENT

[Linus Torvalds]

On Fri, 15 Nov 2002, Jamie Lokier wrote:
> 
> Once you're talking about nanoseconds, you can have both: each time
> you store an mtime, make sure the value is at least 1 nanosecond
> greater than the previously stored mtime for any file in the
> serialisation domain.  If it is not, simply _wait_ for up to a
> nanosecond until the value has advanced enough.

Note that the fields already _are_ nanoseconds, it's just not updated at a
nanosecond rate. We're updating xtime only at a rate of HZ, where the 1 ms
comes from in 2.5.x.

And doing a full "gettimeofday()" sounds just a bit too expensive for the
stuff that needs to just update an inode time field.

But the thing is, we don't actually care about the exact time, we only
care about it being monotonically increasing, so I suspect we could just
have something like

	static unsigned long xtime_count;

	static struct timespec current_time(void)
	{
		struct timespec val;
		unsigned long extra;

		read_lock_irq(&xtime_lock);
		val = xtime;
		extra = xtime_count;
		xtime_count = extra+1;
		read_unlock_irq(&xtime_lock);

		val.nsec += count;
		if (val.tv_nsec > 1000000000) {
			val.tv_nsec -= 1000000000;
			val.tv_sec ++;
		}
		return val;
	}

and then have the timer clear "xtime_count" every time it updates it.  

This obviously doesn't give us nanosecond resolution, but it _does_ give
us "unique" timestamps (assuming a system call takes longer than a
nanosecond, which is likely true for the next decade or so - after that we
can start worrying about whether the users might be outrunning the clock).

		Linus