Messages in this thread | ![/](/images/icornerl.gif) | | From | Shawn Leas <> | Subject | RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) | Date | Mon, 11 Oct 1999 12:58:05 -0500 |
| |
From: Horst von Brand [mailto:vonbrand@sleipnir.valparaiso.cl] Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device allocation))
>> 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/
| ![\](/images/icornerr.gif) |