On 4/20/05, Bryan Henderson <[EMAIL PROTECTED]> wrote: > >In essense, I was > >thinking of splitting up the concepts of 1) accessing the filesystem on > >the HDD/device and 2) setting up a namespace for accessing the files > >into two separate concepts > > I've been crusading for years to get people to understand that a classic > Unix mount is composed of these two parts, and they don't have to be > married together. (1) is called creating a filesystem image and (2) is > called mounting a filesystem image. > > (2) isn't actually "setting up" a namespace. There's one namespace. > Mounting is adding the names in a filesystem to that namespace, and > thereby making the named filesystem objects accessible. > > The two pieces have been slowly divorcing over the years. We now have a > little-used ability to have a filesystem image exist without being mounted > at all (you get that by forcibly unmounting a filesystem image that has > open files. The unmount happens right away, but the filesystem image > continues to exist until the last file is closed). We also have the bind > mounts that add to the namespace without creating a new filesystem image. > I would like someday to see the ability to create a filesystem image > without ever mounting it, and access a file in it without ever adding it > to the master file namespace. > > >bringing up 2) completely in the userspace. > > That part's another issue. The user-controls-his-namespace aspect of it > has been commented on at length in this and another current thread. > > -- > Bryan Henderson IBM Almaden Research Center > San Jose CA Filesystems > >
I totally agree with you. I came across this problem mainly because there are a lot of times when I want to install custom software in userspace and there is a limit to what you can do. I don't know if you have looked at the installation procedure of gentoo or not... however, in gentoo you install software by chrooting into an 'install directory' and doing all the installation there. However, chrooting requires root priviledges and for installing and executing software in the userspace... chroot just misses the point. Till now I have been manually doing installs by passing on installation prefixes in the configure scripts... but having a filesystem namespace associated with a process seems to be just so right :-). When I was busy implementing the prototype I had also thought of integrating completely usesspace filesystems (like FUSE) into the usespace namespace. My hope was coming up with an elegant solution to mount and use a device without resorting to any suid binaries or scripts or help from the root. However, again, we should keep in mind the two concepts of 'namespaces' and the 'actual filesystem' separate in the system so that the device can be shared (probably using a different namespace) by another user/process. I get the point that per process filesystem namespaces the way I presented them may have some problems with suid binaries and the way many pieces of software work. I have not used gpg so I am not qualified to say anything for gpg here. I should say that I don't have an idea of the amount of backward compatibility we shall loose if we use my apparoach. However, if I am getting things right, I believe that the backward compatibility is lost just by introducing "user changeable filesystem namespaces" (which in my opinion is a valuable thing to have in an operating system) irrespective of the implementation. -- Rationality is the fundamental limitation to all human thought. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
