Messages in this thread | | | Subject | Re: [patch-2.3.47] /proc/driver/microcode -> /dev/cpu/microcode | From | Jes Sorensen <> | Date | 24 Feb 2000 11:24:02 +0100 |
| |
>>>>> "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/
| |