lkml.org 
[lkml]   [2000]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch-2.3.47] /proc/driver/microcode -> /dev/cpu/microcode
From
Date
>>>>> "Ted" == Theodore Y Ts'o <tytso@MIT.EDU> writes:

Ted> Date: Wed, 23 Feb 2000 16:11:21 +1100 From: Richard Gooch
Ted> <rgooch@atnf.csiro.au>

> 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.

Ted> You know, it wasn't that long ago that you said that using devfs
Ted> should be a choice, and not something that would ever be forced.
Ted> Now you're saying "tough, use devfs". I guess your earlier
Ted> statements were just made to pursuade people to accept it into
Ted> the kernel, and now you're changing your mind?

I second that - I always had the impression that if devfs ever went
into the official kernel it was going to be as an option, leaving
system functional without enabling it.

If devfs is going to be a mandatory I would like to see a statement
about this from Linus.

I would also kinda know why I would want to use it, after all I am
perfectly comfortable with the old style device nods. Richard's
comment about devfs being as vital as /proc is complete bollocks. I
agree completely that a lot of the stuff in /proc is a mess, and it
probably makes a lot of sense to move things like device driver
parameter tuning interfaces somewhere else. However having simple
entries there for reading out kernel information is perfectly fine -
/proc/pci /proc/cpuinfo etc.

Jes


-
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    [from the cache]
©2003-2011 Jasper Spaans