lkml.org 
[lkml]   [2010]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH RFC 0/8] Dynamic clock devices
    From
    Date
    On Thu, 2010-11-04 at 20:26 +0100, Richard Cochran wrote:
    > The clock_ syscalls are moved into a new file and they call the older
    > posix functions when needed. The timer_ syscalls stay where they are,
    > in posix-timers.c, since I did not want to change the fairly involved
    > timer management code. Eventually, we could remove the posix clock_*
    > functions for the CLOCK_* ids from posix-timers.c and rework them
    > using the new dynamic clock api. That would leave just the timer code
    > in posix-timers.c, as the file name suggests.
    >
    > I dropped the idea of having user space open a sysfs file in order to
    > get a reference to a clock, since there are no open/release hooks
    > within sysfs for drivers (coincidentally, there has been some talk
    > about this on the lkml recently, but previously Greg KH object to
    > abusing sysfs as a "clockfs").
    >
    > Instead, since many clocks (hpet, rtc, ptp, ...) will want to offer a
    > custom chardev for special advanced functionality, the dynamic clock
    > layer registers a cdev for the driver, placing its own hooks into the
    > open/release methods. The driver thus needs to access its private data
    > via a standard access method (not just by using fp->private_data). If
    > a driver doesn't want any chardev functions, that is okay, too.
    >
    > Well, please take a look and let me know what you think.

    Hey Richard!
    Thanks for sending this patchset out for review! This is definitely a
    larger redesign from your earlier patch, and I see now how the
    per-thread cputime clockids throws a wrench in my argument just using
    the incremental clockids that hash into a smaller array to avoid id
    reuse.

    That said, given how different this is from the last implementation, I'm
    not fully clear I see how to integrate this into my patch set. It might
    be useful to see a trivial example of how you see a clockdevice being
    registered and used.

    Overall it looks interesting, but there may be a few catches that we may
    have to watch out for.

    I have a few other comments I'll make in context of the patches to
    follow shortly.

    thanks again!
    -john



    \
     
     \ /
      Last update: 2010-11-09 00:03    [W:0.023 / U:90.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site