my proposal for Glendix Filesystem Hierarchy

55 views
Skip to first unread message

Henry Huang

unread,
Apr 7, 2009, 6:03:43 AM4/7/09
to gle...@googlegroups.com
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
|   `-- 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

unread,
Apr 7, 2009, 7:26:26 AM4/7/09
to gle...@googlegroups.com, Henry Huang
So this would be equal to /usr/bin? And what about the nongnu software
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
>

Is there any special reason why /home/username isnt used?

>
> 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.

You could do the exact same thing easier and quicker by using OE recipes.

>
> i will research on Pacman in ArchLinux and "Compile" in GoboLinux, and
> exploit "Compile" way to patch Pacman for our Glendix Filesystem.

Not sure if this is the proper place to have this, but Im not sure I agree
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

unread,
Apr 7, 2009, 7:54:10 AM4/7/09
to gle...@googlegroups.com
it is plan9-like, so no /home/username but /usr/username.
You're right but to pull out a glendix distro in three months maybe it
is a good choice.


>
>>
>> >
>
>
> --
> Kristoffer Ericson <kristoffe...@gmail.com>
>
> >
>

J.R. Mauro

unread,
Apr 7, 2009, 4:32:06 PM4/7/09
to gle...@googlegroups.com
On Tue, Apr 7, 2009 at 6:03 AM, Henry Huang <henry....@gmail.com> wrote:
>
> 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

I forsee this kicking you in the ass. As much as no one is supposed to
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
/sys will not work on Linux. sysfs is mounted there. I nominate /usr/sys or /src

> /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 think having a personal /bin in everyone's $HOME is much better.

>
> i will research on Pacman in ArchLinux and "Compile" in GoboLinux, and
> exploit "Compile" way to patch Pacman for our Glendix Filesystem.

Please, not pacman. I know emerge is big and hard to understand at
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

unread,
Apr 7, 2009, 10:19:34 PM4/7/09
to gle...@googlegroups.com
Thank you for giving me so many advices :)
That's all right. i am not quite familiar with filesystem layout design.
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
ye, that's true.

> 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.
ah, i miss this part:(
Actually pacman has its PKGBUILD, similar to ebuilds, easy to modify too

J.R. Mauro

unread,
Apr 7, 2009, 10:25:06 PM4/7/09
to gle...@googlegroups.com
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.
And with zero dependency checking. Possibly fine for Plan 9 things,
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

unread,
Apr 8, 2009, 9:33:31 AM4/8/09
to gle...@googlegroups.com
On 08-Apr-09, at 4:25 AM, J.R. Mauro wrote:
>>> 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

unread,
Apr 8, 2009, 10:31:22 AM4/8/09
to gle...@googlegroups.com
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.

-- Chris

Kristoffer Ericson

unread,
Apr 8, 2009, 12:07:20 PM4/8/09
to gle...@googlegroups.com, J.R. Mauro
On Tue, 7 Apr 2009 22:25:06 -0400
I agree with the pacman dep issue, on the other side both
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

unread,
Apr 8, 2009, 12:10:11 PM4/8/09
to gle...@googlegroups.com, Christopher Brannon
On Wed, 08 Apr 2009 09:31:22 -0500
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.

Both /sys and /proc will be nasty yes.
>
> 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.

Its better to seperate linux/plan9 structures agreed. Its always nice though
to have the relevant folders directly under /, so perhaps just a suffix?
like /sys9, proc9,...

>
> -- Chris
>
> >


--
Kristoffer Ericson <kristoffe...@gmail.com>

Uriel

unread,
Apr 10, 2009, 5:26:29 AM4/10/09
to gle...@googlegroups.com
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.)

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

unread,
Apr 10, 2009, 4:13:12 PM4/10/09
to gle...@googlegroups.com
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.

>
> 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.)

Honestly, staying agnostic would be best, especially if we do what you
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.

Sounds like we could get more people that way. In-place upgrades are
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

unread,
Apr 15, 2009, 9:43:40 AM4/15/09
to gle...@googlegroups.com
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

Jorden Mauro

unread,
Apr 15, 2009, 12:18:17 PM4/15/09
to gle...@googlegroups.com, gle...@googlegroups.com




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?


Bind mounts are still flakey. Namespaces require root privs

Uriel

unread,
Apr 17, 2009, 7:46:45 PM4/17/09
to gle...@googlegroups.com
> 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

unread,
Apr 17, 2009, 7:48:35 PM4/17/09
to gle...@googlegroups.com
Oh, and there are already workarounds to the root limitation, see the
9mount tools which run as suid (yuck).

http://sqweek.dnsdojo.org/code/9mount/

uriel

Jorden Mauro

unread,
Apr 17, 2009, 7:52:56 PM4/17/09
to gle...@googlegroups.com, gle...@googlegroups.com




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.

Whoops. I knew that. Sorry


>
>
> 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?

> uriel
>
> >

Uriel

unread,
Apr 19, 2009, 3:54:52 PM4/19/09
to gle...@googlegroups.com
>> 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.

Could just as well say 'We could employ 9mount', which has its own
hacks to do pretty much the same.

uriel

J.R. Mauro

unread,
Apr 19, 2009, 4:10:49 PM4/19/09
to gle...@googlegroups.com
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
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.

9mount is far less reliable than FUSE in my experience, besides being
siud root. I've also had serious issues trying to unmount things
mounted with 9mount.

>
> uriel
>
> >
>

Uriel

unread,
May 2, 2009, 11:25:00 AM5/2/09
to gle...@googlegroups.com
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.

> 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

unread,
May 2, 2009, 12:29:52 PM5/2/09
to gle...@googlegroups.com
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. 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

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?

>
>> 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.

>
> uriel
>
> >
>

Uriel

unread,
May 2, 2009, 2:27:50 PM5/2/09
to gle...@googlegroups.com
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.

> 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

unread,
May 2, 2009, 2:38:57 PM5/2/09
to gle...@googlegroups.com
On Sat, May 2, 2009 at 2:27 PM, Uriel <lost....@gmail.com> wrote:
>
> 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.

I didn't say it wouldn't, just that it's been buggered before
(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.

I suppose that would work.

>
>> 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.

xorgfs is an ugly hack. It may help us in some ways, but I think we're
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.

Right, and if all FUSE did was let you mount things without being
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...

I told sqweek about the problems I had with 9umount. I told ericvh
about the problems I've had with v9fs (like some things hanging my
machine)

>
> Peace
>
> uriel
>
> >
>
Reply all
Reply to author
Forward
0 new messages