Messages in this thread | | | Date | Wed, 23 Feb 2000 08:13:20 +1100 | From | Richard Gooch <> | Subject | Re: [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.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |