Hi!
Alexander Viro wrote:
>
[...]
>
> Having. Multiple. Detries. For. One. Writable. Directory. Is. Broken.
> Having multiple inodes for such directory is absolutely broken.
> Mounting devfs several times gives you exactly that. Ergo, it is broken.
>
> Mount-patches will not save you unless you'll go for several independent
> dentry trees - one for each driver. _Methods_ can and should be the same,
> indeed. So no bloat is induced - just that either have each of these trees
> _once_ and every "devfs" mountpoint refers to several such trees _or_ you
> got a broken kernel.
>
> There is no way to share _part_ of the tree. So if you have one tree you
> either not share it at all (see above) or you need to mount on
> all-or-nothing basis.
>
[...]
Alexander, could you please explain that to me a little bit more?
What are the security issues? I'm not a kernel guru, so I can't really
take part in that in-depth diskussion.
But what I want to say is that we use devfs for several months now
and we are very happy to have it! Many thanks to Richard!
This ongoing discussion about devfs makes me a little bit nervous,
and this is why: we made a special Linux distribution for diskless
workstations, which is now installed on several customer sites.
On our diskless clients we boot from the network and mount our root-fs
from a NFS server read-only. The system is still a fully functional
Linux workstation, not just a terminal!. In fact, I'm sitting in
front of one right now, with Netscape, StarOffice, Emacs, KDE and
several kvt terminal windows running _locally_ without any harddrive!
The workstaion I use right now has 64MB of RAM and uses NBD swap
with 56MB swapped out to our swap-server. Works just fine!
Before we had devfs we couldnīt really solve the problem of having
writable devicefiles on a readonly filesystem.
Now we just mount devfs as early as possible (in initrd) to "/dev/"
and everything works just fine. We even got almost rid of any old
compatibility device. There are only a few applications left
which need the old devicenames (mostly because of lockfiles
named after the devicefile). We try to patch those applications,
so that they can deal with devicefiles like "/dev/tts/0" (as far
as I know there is no Unix specification which defines a flat
namespace under "/dev/", so in my opinion applications which can't
deal with the new names are broken)
We still run devfsd, but mostly for auto-loading device-drivers
and for changing ownership of devicefiles.
We are now using Linux 2.2.14 and we are very happy that devfs found
it's way into the future standard kernel!
Over the past months we ported devfs to 2.2 kernel releases and sent
Richard our patches. It was very easy to do.
So, please, don't misunderstand my intention. I don't want to join a
holy war. I just want to express my thanks to Richard for his work.
I also want to state that we need some sort of devfs for our diskless
clients. If anyone is considering work in this area, please keep in
mind that there are applications like ours which benefit from the way
devfs is working right now! Perhaps we could do it in a different way,
but right now I don't see how.
Thank you!
- andreas
-- Andreas Haumer | mailto:andreas@xss.co.at *x Software + Systeme | http://www.xss.co.at Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0 A-1100 Vienna, Austria | Fax: +43-1-6060114-71- 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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:11 EST