lkml.org 
[lkml]   [2005]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH] new timeofday core subsystem (v. A3)
    From
    Date
    On Mon, 2005-03-14 at 11:29 -0800, Matt Mackall wrote:
    > On Mon, Mar 14, 2005 at 10:42:45AM -0800, john stultz wrote:
    > >
    > > > > +static inline cycle_t read_timesource(struct timesource_t* ts)
    > > > > +{
    > > > > + switch (ts->type) {
    > > > > + case TIMESOURCE_MMIO_32:
    > > > > + return (cycle_t)readl(ts->mmio_ptr);
    > > > > + case TIMESOURCE_MMIO_64:
    > > > > + return (cycle_t)readq(ts->mmio_ptr);
    > > > > + case TIMESOURCE_CYCLES:
    > > > > + return (cycle_t)get_cycles();
    > > > > + default:/* case: TIMESOURCE_FUNCTION */
    > > > > + return ts->read_fnct();
    > > > > + }
    > > > > +}
    > > >
    > > > Wouldn't it be better to change read_fnct to take a timesource * and
    > > > then change all the other guys to generic_timesource_<foo> helper
    > > > functions? This does away with the switch and makes it trivial to add
    > > > new generic sources. Change mmio_ptr to void *private.
    > >
    > > Not sure if I totally understand this, but originally I just had a read
    > > function, but to allow this framework to function w/ ia64 fsyscalls (and
    > > likely other arches vsyscalls) we need to pass the raw mmio pointers.
    > > Thus the timesource type and switch idea was taken from the time
    > > interpolator code.
    >
    > Well for vsyscall, we can leave the mmio_ptr and type. But in-kernel,
    > I think we'd rather always call read_fnct with generic helpers than hit this
    > switch every time.

    Huh. So if I understand you properly, all timesources should have valid
    read_fnct pointers that return the cycle value, however we'll still
    preserve the type and mmio_ptr so fsyscall/vsyscall bits can use them
    externally?

    Hmm. I'm a little cautious, as I really want to make the vsyscall
    gettimeofday and regular do_gettimeofday be a similar as possible to
    avoid some of the bugs we've seen between different gettimeofday
    implementations. However I'm not completely against the idea.

    Christoph: Do you have any thoughts on this?


    > > > > + if (time_suspend_state != TIME_RUNNING) {
    > > > > + printk(KERN_INFO "timeofday_suspend_hook: ACK! called while we're suspended!");
    > > >
    > > > Line length. Perhaps BUG_ON instead.
    > >
    > > Eh, its not fatal to BUG_ON seems a bit harsh. I'll fix the line length
    > > though.
    >
    > Well there's a trade-off here. If it's something that should never
    > happen and you only printk, you may never get a failure report
    > (especially at KERN_INFO). It's good to be accomodating of external
    > errors, but catching internal should-never-happen errors is important.

    Fair enough.


    > > > Excellent question.
    > >
    > > Indeed. Currently jiffies is used as both a interrupt counter and a
    > > time unit, and I'm trying make it just the former. If I emulate it then
    > > it stops functioning as a interrupt counter, and if I don't then I'll
    > > probably break assumptions about jiffies being a time unit. So I'm not
    > > sure which is the easiest path to go until all the users of jiffies are
    > > audited for intent.
    >
    > Post this as a separate thread. There are various thoughts floating
    > around on this already.

    I'm a little busy with other things today, but I'll try to stir up a
    discussion on this soon.

    thanks
    -john


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

    \
     
     \ /
      Last update: 2005-03-22 14:11    [W:0.056 / U:12.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site