>> Also, the current USB device naming system in 2.3.20 is a very ugly
kludge
>> that can go away with devfs.
>It could go away in other ways to. Why _must_ it be devfs?
How about the fact that to solve all the problems it solves you require
many individual solutions. Not the way to go in an OS, where races and
locking issues run rampant. The fact is, devfs skirts many issues, not
only fixing them, but every so gracefully removing the problem by not
doing device management in a way that caused the problem in the first
place.
>> by making things easier...
>... and others impossible/hard.
Which, pray tell?
>> FreeBSD has devfs. Is FreeBSD not Unix?
>Never looked into that.
Obviously.
>> Only at the source level if CONFIG_DEVFS is not set, and the changes
>> needed at source level are so minimal that someone with no previous
kernel
>> programming experience could do it in half an hour.
>If it is set, it impacts all over. Bloat; stability and security suffer.
Ok, Mr gcc, just exactly how is security affected? Instead
of making baseless allegations, please cite fact, at least
at a fundamental level.
>> True. But they won't affect you if you say CONFIG_DEVFS=N.
>If the CONFIG_DEVFS handling is badly implemented, it can screw up other
>code, even when disabled.
Now you insult Richard. You haven't even looked at the patch, or the FAQ.
-Shawn
-
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/