[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.082 / U:0.328 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site