my proposal for Glendix Filesystem Hierarchy
Henry Huang
any suggestion or criticism is appreciated :)
----------------------------
Glendix Filesystem Hierarchy
----------------------------
/
|-- /bin
|-- /boot
|-- /dev
|-- /etc
|-- /gnu
|-- |-- bin
| |-- sbin
| |-- lib
| |-- usr
| | |-- bin
| | |-- include
| | |-- lib
| | |-- sbin
| | |-- share
| | |-- src
| | `-- X11R6
| `-- var
| |-- cache
| |-- lib
| |-- lock
| |-- log
| |-- run
| |-- spool
| `-- tmp
|-- /lib
|-- /net
| |-- tcp
| |-- udp
| `-- ...
|-- /proc
|-- /sys
| |-- doc
| |-- src
| |-- share
`-- /usr
|-- name_of_user1
|-- name_of_user2
`-- ...
/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
BTW:
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:
http://www.gobolinux.org/index.php?page=at_a_glance
-------------------------------
Layout of GoboLinux filesystem
-------------------------------
~] cd /
/] ls
Programs Users System Files Mount Depot
-------------------------------
Two things in GoboLinux make me feel interesting:
[1] 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.
[2] 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
that automatically.
i will research on Pacman in ArchLinux and "Compile" in GoboLinux, and
exploit "Compile" way to patch Pacman for our Glendix Filesystem.
Kristoffer Ericson
that eventually will need to be supported?
> /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
>
>
> BTW:
>
> 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:
> http://www.gobolinux.org/index.php?page=at_a_glance
> -------------------------------
> Layout of GoboLinux filesystem
> -------------------------------
> ~] cd /
> /] ls
> Programs Users System Files Mount Depot
> -------------------------------
>
> Two things in GoboLinux make me feel interesting:
> [1] 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.
>
> [2] 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
> that automatically.
>
> i will research on Pacman in ArchLinux and "Compile" in GoboLinux, and
> exploit "Compile" way to patch Pacman for our Glendix Filesystem.
with your choice of package manager. Granted that pacman is fast (im an archlinux user myself),
but if you need to easily patch and compile with minimal fuzz pacman isnt the thing to use.
Theres also the point of multiarch support that may be relevant in the future, locking yourself
to an currently x86 only packagemanager isnt the way to go.
Ive also seen some major speed decline in pacman as it continues to grow.
>
> >
--
Kristoffer Ericson <kristoffe...@gmail.com>
Henry Huang
is a good choice.
>
>>
>> >
>
>
> --
> Kristoffer Ericson <kristoffe...@gmail.com>
>
> >
>
J.R. Mauro
>
> it is my proposal for Glendix Filesystem Hierarchy.
> any suggestion or criticism is appreciated :)
>
> ----------------------------
> Glendix Filesystem Hierarchy
> ----------------------------
> /
> |-- /bin
> |-- /boot
> |-- /dev
> |-- /etc
> |-- /gnu
> |-- |-- bin
> | |-- sbin
> | |-- lib
> | |-- usr
> | | |-- bin
> | | |-- include
> | | |-- lib
> | | |-- sbin
> | | |-- share
> | | |-- src
> | | `-- X11R6
assume that it's not /usr/X11R6, I'm sure someone does. Kludging the
path would work fairly well for /gnu/bin, but I would just keep the
layout the same as it is and drastically reduce the amount of work
needed. The only problem with /usr/bin and /usr/local/bin is that no
one (read: ubuntu) actually uses it right. Gentoo actually obeys the
spirit of the FHS: /bin is for the things everyone needs, /usr/bin is
for "user" binaries, and /usr/local/bin is for the sysadmin to trash.
Keeping things like that in /usr necessitated the move to /home. For
Plan 9, I would make links in /usr to the directories in /home
> /usr/username Home Directories for users
>
>
> BTW:
>
> 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:
> http://www.gobolinux.org/index.php?page=at_a_glance
> -------------------------------
> Layout of GoboLinux filesystem
> -------------------------------
> ~] cd /
> /] ls
> Programs Users System Files Mount Depot
> -------------------------------
>
> Two things in GoboLinux make me feel interesting:
> [1] 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.
>
> [2] 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
> that automatically.
>
> i will research on Pacman in ArchLinux and "Compile" in GoboLinux, and
> exploit "Compile" way to patch Pacman for our Glendix Filesystem.
times, but maybe you could modify that? I think writing ebuilds for
all the Plan 9 programs would be fairly simple, especially since one
could have the ebuilds just mount sources via 9P on /n to get the
source code. Thus a Glendix "distro" is as easy as rolling up gentoo
with a fun little overlay.
>
> >
>
Henry Huang
Actually i wish guys like you would give me suggestions or criticism.
That's important! :P
> assume that it's not /usr/X11R6, I'm sure someone does. Kludging the
> path would work fairly well for /gnu/bin, but I would just keep the
> layout the same as it is and drastically reduce the amount of work
> needed. The only problem with /usr/bin and /usr/local/bin is that no
> one (read: ubuntu) actually uses it right. Gentoo actually obeys the
> spirit of the FHS: /bin is for the things everyone needs, /usr/bin is
> for "user" binaries, and /usr/local/bin is for the sysadmin to trash.
>
> Keeping things like that in /usr necessitated the move to /home. For
> Plan 9, I would make links in /usr to the directories in /home
>
applications located in /gnu directory.
J.R. Mauro
break so bad you can't get it sane. I mean, hey, maybe it will work,
but I see GNU doing stupid things all over the place. I think merging
the two FH layouts would be the best option, especially since Plan 9's
will map fairly trivially into the standard Linux one. I.e., you'll
probably only have to drop some symlinks in or something like that.
but too bare for my tastes. I think a nice Gentoo overlay would be
best, but hey, what do I know.
In any event, you might pursue a nice new way of getting p9p
installed, since you can bootstrap the p9p "9fs" script, then mount
sources and bring in whatever you want via that.
I'd love to see an overlay.
Anant Narayanan
>>> spirit of the FHS: /bin is for the things everyone needs, /usr/bin
>>> is
>>> for "user" binaries, and /usr/local/bin is for the sysadmin to
>>> trash.
>>>
>>> Keeping things like that in /usr necessitated the move to /home. For
>>> Plan 9, I would make links in /usr to the directories in /home
>>>
>> In fact, i aim to create a Plan9-like filesystem layout with GNU
>> applications located in /gnu directory.
>
> Well, as I said, the above layout might make all of the GNU userspace
> break so bad you can't get it sane. I mean, hey, maybe it will work,
> but I see GNU doing stupid things all over the place. I think merging
> the two FH layouts would be the best option, especially since Plan 9's
> will map fairly trivially into the standard Linux one. I.e., you'll
> probably only have to drop some symlinks in or something like that.
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
applications.
>>> /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?
--
Anant
Christopher Brannon
> 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.
-- Chris
Kristoffer Ericson
rpm and apt are dep crazy. Even gotten some nice
circular deps at times. Gentoo style is nice though.
Perhaps even ipkg/opkg.
> >
> >> all the Plan 9 programs would be fairly simple, especially since one
> >> could have the ebuilds just mount sources via 9P on /n to get the
> >> source code. Thus a Glendix "distro" is as easy as rolling up gentoo
> >> with a fun little overlay.
> >>
> >>>
> >>> >
> >>>
> >>
> >> >
> >>
> >
> > >
> >
>
> >
Kristoffer Ericson <kristoffe...@gmail.com>
Kristoffer Ericson
Christopher Brannon <cmbra...@gmail.com> wrote:
>
> Anant Narayanan wrote:
> > 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.
to have the relevant folders directly under /, so perhaps just a suffix?
like /sys9, proc9,...
>
> -- Chris
>
> >
--
Kristoffer Ericson <kristoffe...@gmail.com>
Uriel
Just keep a /linux/ directory with the standard linux hierarchy, and
before you run any linux apps, you bind / /linux/mnt/9/; bind /linux/
/; (Or equivalent.)
As for package management, why on earth would you need one? Isn't like
any Plan 9 software uses any kind of package management, other than
perhaps fgb's contrib(1), which should 'just work' as is. (If you want
to pick a package management for the linux side of things, then just
pick the simplest you can find, and be done with it.)
By the way, it might make sense (at least initially) to inverse
things, and simply have a /9/ directory which is bound to / before
running plan9 applications, that will allow one to install glendix
side-by-side any existing linux distribution.
Peace
uriel
J.R. Mauro
>
> There is a very simple solution to all this problems: namespaces!
>
> Just keep a /linux/ directory with the standard linux hierarchy, and
> before you run any linux apps, you bind / /linux/mnt/9/; bind /linux/
> /; (Or equivalent.)
>
> As for package management, why on earth would you need one? Isn't like
> any Plan 9 software uses any kind of package management, other than
> perhaps fgb's contrib(1), which should 'just work' as is. (If you want
> to pick a package management for the linux side of things, then just
> pick the simplest you can find, and be done with it.)
said in the next paragraph. We shouldn't care about whether the
userland uses emerge or apt or rpm. We should probably have contrib,
although we might want/need to modify it.
I'm not too familiar with contrib--does it keep track of what is
already installed and where? Obviously it doesn't need to worry about
dependencies, but keeping track of state is nice.
>
> By the way, it might make sense (at least initially) to inverse
> things, and simply have a /9/ directory which is bound to / before
> running plan9 applications, that will allow one to install glendix
> side-by-side any existing linux distribution.
the best kind.
Though I suppose having either layout as an option makes sense. Again,
it hinges on getting namespaces in better shape than they are now.
Uriel
>
> On Fri, Apr 10, 2009 at 5:26 AM, Uriel <lost....@gmail.com> wrote:
>>
>> There is a very simple solution to all this problems: namespaces!
>
> Assuming we can get them working first, yes, that's fine.
that require further work?
uriel
Jorden Mauro
On Apr 15, 2009, at 9:43, Uriel <lost....@gmail.com> wrote:
>
> On Fri, Apr 10, 2009 at 10:13 PM, J.R. Mauro <jrm...@gmail.com>
> wrote:
>>
>> On Fri, Apr 10, 2009 at 5:26 AM, Uriel <lost....@gmail.com> wrote:
>>>
>>> There is a very simple solution to all this problems: namespaces!
>>
>> Assuming we can get them working first, yes, that's fine.
>
> Namespaces and bind mounts work right now. What issues do you have
> that require further work?
Uriel
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.
uriel
Uriel
9mount tools which run as suid (yuck).
http://sqweek.dnsdojo.org/code/9mount/
uriel
Jorden Mauro
On Apr 17, 2009, at 19:46, Uriel <lost....@gmail.com> wrote:
>
>> Bind mounts are still flakey. Namespaces require root privs
>
> 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.
>
> uriel
>
> >
Uriel
>> solve that no matter what for all other kinds of stuff you need to
>> mount in your namespace.
>>
>
> Maybe we could employ FUSE initially?
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
such hacks.
Could just as well say 'We could employ 9mount', which has its own
hacks to do pretty much the same.
uriel
J.R. Mauro
>
>>> 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.
>>>
>>
>> Maybe we could employ FUSE initially?
>
> 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
> such hacks.
employ it to mount whatever you want without having to be root, and
there are actually union filesystems on top of FUSE (dunno how well
they work, but IIRC one attempts to mimic Plan 9's concepts).
>
> Could just as well say 'We could employ 9mount', which has its own
> hacks to do pretty much the same.
siud root. I've also had serious issues trying to unmount things
mounted with 9mount.
>
> uriel
>
> >
>
Uriel
>
> On Sun, Apr 19, 2009 at 3:54 PM, Uriel <lost....@gmail.com> wrote:
>>
>>>> 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.
>>>>
>>>
>>> Maybe we could employ FUSE initially?
>>
>> 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
>> such hacks.
>
> What do you mean there's nothing in FUSE to solve the problem? You can
> employ it to mount whatever you want without having to be root, and
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.
uriel
J.R. Mauro
>
> On Sun, Apr 19, 2009 at 10:10 PM, J.R. Mauro <jrm...@gmail.com> wrote:
>>
>> On Sun, Apr 19, 2009 at 3:54 PM, Uriel <lost....@gmail.com> wrote:
>>>
>>>>> 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.
>>>>>
>>>>
>>>> Maybe we could employ FUSE initially?
>>>
>>> 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
>>> such hacks.
>>
>> What do you mean there's nothing in FUSE to solve the problem? You can
>> employ it to mount whatever you want without having to be root, and
>
> 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.
results /now/ and without having to modify the kernel. 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. 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.
>
>> 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.
>
> uriel
>
> >
>
Uriel
>
> On Sat, May 2, 2009 at 11:25 AM, Uriel <lost....@gmail.com> wrote:
>>
>> On Sun, Apr 19, 2009 at 10:10 PM, J.R. Mauro <jrm...@gmail.com> wrote:
>>>
>>> On Sun, Apr 19, 2009 at 3:54 PM, Uriel <lost....@gmail.com> wrote:
>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Maybe we could employ FUSE initially?
>>>>
>>>> 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
>>>> such hacks.
>>>
>>> What do you mean there's nothing in FUSE to solve the problem? You can
>>> employ it to mount whatever you want without having to be root, and
>>
>> 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.
>
> I didn't say we had to depend on it forever. It would simply give us
> results /now/ and without having to modify the kernel.
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
hard.
> 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...
Peace
uriel
J.R. Mauro
>
> On Sat, May 2, 2009 at 6:29 PM, J.R. Mauro <jrm...@gmail.com> wrote:
>>
>> On Sat, May 2, 2009 at 11:25 AM, Uriel <lost....@gmail.com> wrote:
>>>
>>> On Sun, Apr 19, 2009 at 10:10 PM, J.R. Mauro <jrm...@gmail.com> wrote:
>>>>
>>>> On Sun, Apr 19, 2009 at 3:54 PM, Uriel <lost....@gmail.com> wrote:
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> Maybe we could employ FUSE initially?
>>>>>
>>>>> 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
>>>>> such hacks.
>>>>
>>>> What do you mean there's nothing in FUSE to solve the problem? You can
>>>> employ it to mount whatever you want without having to be root, and
>>>
>>> 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.
>>
>> I didn't say we had to depend on it forever. It would simply give us
>> results /now/ and without having to modify the kernel.
>
> 9mount would do exactly the same.
(actually, 9umount was the thing that had problems, but they may not
affect using it for --bind)
>
>> 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
> hard.
>
>> 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.
much better off working on top of the framebuffer (even if it is
almost too hard)
>
>
>>>> 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.
root, it would be "less sneaky" too. Thing is, FUSE is supposed to do
much more than that, and you just get userspace mounting for free.
>
>>>> 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...
about the problems I've had with v9fs (like some things hanging my
machine)
>
> Peace
>
> uriel
>
> >
>