>Yes, you are missing something here. The entire point is that devfs is
>not getting into the kernel in its current form. There has been really
>strong opposition from some very high-ranking kernel developers. It is
>pointless to continue the argument using the existing devfs. It simply
>is Not Going To Happen. There's no point fighting that.
Only because people misunderstand. Some of these high level kernel zealots
are even higher level arrogent when it comes to device filesystem because
it makes the system admins job more automatic, and they might be antiquated.
Imagine, sysadmins wouldn't have to look in /proc/devices to figure out how
to create /dev/hda when some of /dev gets blown away, and there's no
MAKEDEV.
Oh my goodness! Think of how easy it would be! How F*CKING HORRIBLE!!!
>This is why I suggested losing the devfs FILESYSTEM but retaining what
>is devfs's INTENTION. Use the existing devfsd to maintain nodes on the
>disk. Most of the benefits are kept. Some problems are addressed.
The FS layer is minimal. The existing (ie, unnacceptable) devfs does not
suffer bloat from exporting a fs view of the device nodes. It, via this
mechanism, gets away with registering devices in nearly limitless amounts,
while being descriptive, and really NOT straying from the whole idea of
how devices are registered. This is the only way to get out of the
major/minor limitation in a SCALABLE way!!!
-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/