lkml.org 
[lkml]   [2000]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch-2.3.47] /proc/driver/microcode -> /dev/cpu/microcode
greerga@nidhogg.ham.muohio.edu writes:
> On Wed, 23 Feb 2000, Richard Gooch wrote:
>
> >Jeff Garzik writes:
> >> Richard Gooch wrote:
> >> > > 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.
> >>
> >> Devfs _is not_ the place for generic, driver-specific text output to
> >> userspace.
>
> For all these things being moved to /dev from /proc, are
> major/minors going to be created so people can use on-disk /dev or
> shall it be a "tough, use devfs" attitude?

I'd advocate we move from a "tough, use procfs" attitude to a "tough,
use devfs" attitude. If you don't want to have devfs in your kernel,
you wouldn't want procfs either (if being consistent). After all,
devfs doesn't *have* to be mounted over /dev.

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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.189 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site