> I have never posted anything stating that you were "forcing" me to do
> anything. What I have posted are two simple statements which neither
> Shawn Leas or Richard Gooch have answered.
> I have repeated them below.
>
> 1. Companies, clients, and I like the current naming conventions,
> and want to keep using the current naming conventions.
You can, even with DEVFS. Just enable full compatibility if you want to
be paranoid. Richard has also stated that he will be reviewing the FAQ,
and making sure this factoid is ebroidered well enough for the blind to
see.
> 2. What advantage does dev_fs offer us over the present system?
> Understand that we do not care about thousands & thousands of
> inodes in /dev, we do not care about directory searches being slow.
> So given that what are the advantages?
1) Less administrative overhead, as /dev device nodes are automatic. This
would appeal to ANY admin or company.
2) FULL backwards compatibility with old device name standard.
3) Speed of having these nodes free of filesystem baddies, like dentry
lookup, etc, which you don't care about for some reason which you have not
divulged.
> > Yeah, but the alternatives are arranged as one solution per
> > problem. Devfs is arranged as one solution for many problems. And best
> > of all, it's *optional*.
>
> What is "wrong" with one solution per problem?
devfs solve problems at the root cause, it's very nature causes the
problems to NOT BE ABLE TO EXIST. You are bypassing the very problematic
nature of having device inodes on a FS on disk, and causing NONE, count
them, no new problems in the process. Completely backwards compatible!
Even Theo's solution involves a new way of thinking about things, having
/proc
|
\volumes
|
|\NT_5.0
|
\whateverFAT
Is quite a difference from mounting /dev/sda1 onto /usr.
> I have the impression that if anyone suggests that alternatives be
> investigated that you view that as "opposing" dev_fs. Just as you are
> requesting that I respect other views, I ask that you also respect
> the views of the companies, clients, and myself.
OK, I have answered your questions, and I would appreciate it if you
acknowledged it rather than saying I/we are skirting or dodging them.
> General principles I go by:
>
> 1. The simplest solution is usually the best.
> 2. Resolve a single problem with the simplest solution.
> 3. Resolving many problems with one solution is generally not the
> simplest
> solution.
All or most of the problems cited by the current /dev/ setup are caused by
a single situation, that is having device inodes created from userland
sitting in /dev, regardless if you have that device or not, and it, IMHO,
is a hack.
The devfs is like the thing that was never there but should have been! It
solves all problems at the root cause, not bandaid them.
Years of exposure to UNIX like OSes have blinded people into thinking that
userland takes care of device node management, when I really think that
the DRIVER has some say in it to, while ALSO giving userland complete
flexibility!!!!! Ha!
-Shawn
<=========== America Held Hostage ===========>
Day 2023 for the poor and the middle class.
Day 2042 for the rich and the dead.
899 days remaining in the Raw Deal.
<============================================>
-
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.altern.org/andrebalsa/doc/lkml-faq.html