Glendix Filesystem Hierarchy
|-- |-- bin
| |-- sbin
| |-- lib
| |-- usr
| | |-- bin
| | |-- include
| | |-- lib
| | |-- sbin
| | |-- share
| | |-- src
| | `-- X11R6
| `-- var
| |-- cache
| |-- lib
| |-- lock
| |-- log
| |-- run
| |-- spool
| `-- tmp
| |-- tcp
| |-- udp
| `-- ...
| |-- doc
| |-- src
| |-- share
/bin Glendix Binaries, like execute binaries in p9pack_u1.tar.gz
/boot Glendix Boot, default -- grub
/dev,/proc Special kernel filesystems for device and process
/etc Glendix Configuration FIles
/gnu GNU applications
/lib Glendix Libraries
/net API for all TCP/IP
/sys/doc Glendix Documentations
/sys/src Glendix application Source Codes
/sys/share Glendix application Auxiliary files
/usr/username Home Directories for users
Recently i have found a project named GoboLinux, a modular Linux
distribution with a refined new filesystem layout.
Here is the link for introduction of GoboLinux:
Layout of GoboLinux filesystem
~] cd /
Programs Users System Files Mount Depot
Two things in GoboLinux make me feel interesting:
 The Unix paths do not show up in the system root.
Actually they are there, only concealed from view by using the
GoboHide kernel extension.
Maybe we could get advantage of this idea while we need to hide some Unix paths.
 The package manager used in GoboLinux -- Compile
While installing software from source, it is quite easy to use
--prefix=/your/own/prefix in ./configure, or set
PREFIX=/your/own/prefix for Makefiles. GoboLinux use Compile to handle
i will research on Pacman in ArchLinux and "Compile" in GoboLinux, and
exploit "Compile" way to patch Pacman for our Glendix Filesystem.
The idea is to have something like the GoboHide module in kernel as
part of Glendix that will show the user a "pure" Plan9 filesystem
hierarchy, while still retaining compatibility with legacy GNU/Linux
>>> /sys will not work on Linux. sysfs is mounted there. I nominate /
>>> usr/sys or /src
Does anyone have ideas as to how to workaround sysfs?
Doesn't /proc present some problems as well? Plan 9's /proc and Linux's
/proc are wildly different.
I don't have any great ideas, but should Plan 9 programs and native
Linux programs really be sharing the same namespace? An alternative
suggestion is to have a /plan9 hierarchy. All of the Glendix syscalls
treat /plan9 as the root directory.
What is 'flakey' about bind mounts?
There is no way to do unions, but that is not required for my proposal to work.
As for the need to be root to mount stuff, you are going to need to
solve that no matter what for all other kinds of stuff you need to
mount in your namespace.
What for? There is nothing in FUSE that solves this problem. They have
some hacks that anyone can use to deal with this, but they are
certainly not a solution, and one is not required to use FUSE to use
Could just as well say 'We could employ 9mount', which has its own
hacks to do pretty much the same.
Again, there is nothing FUSE-specific about the hacks they use to
allow non-root users to mount stuff.
This are awful hacks that ideally should not exist, but it is even
more dumb to depend on FUSE simply because they happen to implement
them when we could do exactly the same.
> there are actually union filesystems on top of FUSE (dunno how well
> they work, but IIRC one attempts to mimic Plan 9's concepts).
Plan 9 has no 'union file systems', it has *union mounts/binds'. I
don't see how FUSE's unionfs would be of any use even if their
semantics were really close to Plan 9's (which I doubt).
>> Could just as well say 'We could employ 9mount', which has its own
>> hacks to do pretty much the same.
> 9mount is far less reliable than FUSE in my experience, besides being
> siud root.
Suid root seems like a more explicit and less sneaky way to do the
kind of hack FUSE does.
> I've also had serious issues trying to unmount things
> mounted with 9mount.
Then file bugs against v9fs.
9mount would do exactly the same.
> We have a long
> way to go before eliminating suid and the root user, and until we do
> that, anything we do to get user mounts working will be just another
> ugly hack.
Not really, if one uses namespaces properly. One of the problems with
the FUSE people is that they don't understand namespaces. If to allow
non-root mounts we required forking into a new namespace first (and if
this disabled suid), there would be no problem, and AFAIK neither is
> The only difference is that we have to spend time writing
> the ugly hack to throw it away later.
> You seem to be singing two different tunes, since you thought xorgfs
> was a good idea. Make up your mind.
I don't see how this relates to xorgfs, which has use well beyond
Glendix itself, and which should be valuable no matter what.
>>> there are actually union filesystems on top of FUSE (dunno how well
>>> they work, but IIRC one attempts to mimic Plan 9's concepts).
>> Plan 9 has no 'union file systems', it has *union mounts/binds'. I
> I know this.
>> don't see how FUSE's unionfs would be of any use even if their
>> semantics were really close to Plan 9's (which I doubt).
> We get the bind program for free?
>>>> Could just as well say 'We could employ 9mount', which has its own
>>>> hacks to do pretty much the same.
>>> 9mount is far less reliable than FUSE in my experience, besides being
>>> siud root.
>> Suid root seems like a more explicit and less sneaky way to do the
>> kind of hack FUSE does.
> How is it "less sneaky" than what FUSE does?
Because it is more explicit and doesn't rely on kernel changes to
treat certain kinds of fs mounts specially.
>>> I've also had serious issues trying to unmount things
>>> mounted with 9mount.
>> Then file bugs against v9fs.
> I have filed bugs against v9fs and told sqweek.
Sqweek is not in charge of v9fs, so I'm not sure if he can do much
about any of it...