Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

[Dan Hecht]

On 03/06/2007 05:18 PM, Thomas Gleixner wrote:
> On Tue, 2007-03-06 at 16:53 -0800, Dan Hecht wrote:
> > > Ooops. I completely forgot, that you get the absolute expiry time
> > > already in ktime_t format (nanoseconds) when dev->set_next_event() is
> > > called.
> > >
> > > 	dev->next_event = expires;
> > >
> > > is done right before the call. 
> > >
> > > So it's already there for free.
> > Okay.  I noticed that but didn't think it was okay to use since it 
> > didn't seem like it was set up for the clock_event_device code's use, so 
> > seemed like a conceptual interface violation to go digging around in 
> > there.
>
> Yes it is. 
>
> I just wanted to point out that you can use it until I'm awake enough to
> implement it proper.

Well, we'll probably just live with using the relative expiry for the 
first pass, and then revisit this later once that is working, rather 
than resort to hacking it out by reading ->next_event.

> > Also, wasn't one of the points of clockevents to prevent the device code 
> > from doing conversions between nanoseconds and clicks themselves?  Don't 
> > we really want the clockevents generic layer to do this conversion 
> > between monotonic nanonseconds to absolute device clicks and then give 
> > the device code that value, so the device layer doesn't perform any 
> > conversions?
>
> Right. But this applies only to deltas, as the conversion of absolute
> time values gets ugly, i.e. 128bit math

Yeah, hopefully we can come up with a clean way to do this.  But, like I 
said early, until we do, we'll stick with the relative expiry.

> IMO the paravirt interfaces should use nanoseconds anyway for both
> readout and next event programming. That way the conversion is done in
> the hypervisor once and the clocksources and clockevents are simple and
> unified (except for the underlying hypervisor calls).

I disagree.  The clocksource/clockevents layer are always going to have 
to convert nanoseconds to/from hardware units, so why not use it?  And, 
some guests (say, a future version of linux that does trace-based 
process accounting) may want higher resolution than nanoseconds for 
certain uses.  In any case, this is beside the point; I'd prefer to 
stick to using the clockevents interface in the way it was intended 
rather than reaching into ->next_event.

thanks,
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/