[lkml]   [2000]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch-2.3.47] /proc/driver/microcode -> /dev/cpu/microcode
    Tigran Aivazian writes:
    > On Tue, 22 Feb 2000, Richard Gooch wrote:
    > > I don't have /proc/rtc on my machine, but I do have /dev/misc/rtc, so
    > > I don't know where /proc/rtc comes from.
    > Sorry, my typo - I meant /proc/driver/rtc. The source is
    > drivers/char/rtc.c and it does

    OK, I've had a quick squiz at it.

    > create_proc_read_entry ("driver/rtc", 0, 0, rtc_read_proc, NULL);
    > in addition to the binary-data device /dev/rtc (which is in
    > /dev/misc/rtc of devfs). The /proc/driver/rtc is the human-readable
    > dump of RTC data and I thought it should find its proper place in
    > devfs instead of /proc for the same reasons why we moved microcode
    > from /proc/driver to /dev/cpu.

    Yep, it should just be in devfs.

    > > I think we should be strict with the new devfs namespace. If it's not
    > > actually part of the CPU, it doesn't belong in /dev/cpu. If we're not
    > > strict, we end up with the same ad-hockery as /proc.
    > ok, then it could go to /dev/misc/rtc.txt?

    Sigh. It's a pity that the RTC dev driver implements a read() method.
    Otherwise I'd urge a scheme like MTRR: read() for humans and ioctl()
    for programmes.

    Hm. Is the current rtc_read() method actually used by applications?

    Otherwise, /dev/misc/rtc.txt is probably right.



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.022 / U:7.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site