[haiku-development] Re: Question about /system and /boot/system

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 02 Mar 2011 20:04:10 +0100

On 2011-03-02 at 18:52:20 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
[ ... ]
> Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> > > boot
> > >    +-packages
> > >    |  +-system (system packages)
> > >    |  +-common (common packages)
> > >    +-system    (bind mount point for system packages)
> > >    +-common    (bind mount point for common packages)
> > I like that, it  keeps things separate and clear. We just need to
> > find a
> > place for the "settings" folder: we either keep it at
> > /boot/common/settings
> > (and bind-mount that folder from underneath the 'common' packagefs to
> > make it
> > writable) or we could move it elsewhere, maybe /boot/settings? Going
> > with the
> > latter would make both /boot/system and /boot/common completely read-
> > only.
> 
> I like the "shining through" better, though. /boot/common/cache is also
> writable, and they might not end up being the only two entries for
> this.

Ah, right, /boot/common/var is another one. Though with respect to the 
amount of folders that would have to be bind-mounted, there's no difference 
between Truls' and Stephan's layout suggestion. Stephan has just separated 
the 'packages' folder from its mountpoint.

> > One problem I can see with that approach though, is that morphing the
> > user
> > packages into the /boot/system hierarchy won't work at all when we
> > allow
> > multiple concurrent users (unless we implement some very clever
> > strategies
> > that allow the VFS to always determine which real user is trying to
> > access a
> > path).
> 
> Since packagefs always knows the current user, it could just change the
> directory contents on the fly.

How would packagefs know the user when it is being access from input_server 
or the net_server?

> However, I don't really like that solution that much, as you don't have
> a clear distinction between your own and system wide packages, let
> alone how to handle the settings directory in that case.
> 
> The real problem is that some services must not allow morphing their
> files, like when you start certain system applications, they should
> always use the system delivered libraries/settings/whatever instead of
> what the user wants. Also, it gets pretty messy when you want to find
> out about configuration problems, as you just don't know what file
> system a certain user sees (like the root user).
> I think that idea involves too much magic, and could make the system
> quite difficult to understand.

Damn, those are valid concerns, I guess I got a little carried away by the 
cool idea ;-)

cheers,
        Oliver

Other related posts: