[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Passive translators

From: Justus Winter
Subject: Re: Passive translators
Date: Tue, 09 Jul 2013 16:46:13 +0200
User-agent: alot/0.3.4

Hi Thomas :)

Quoting Thomas Schwinge (2013-07-09 15:40:18)
> Hi!
> On Tue, 09 Jul 2013 15:00:00 +0200, Justus Winter 
> <4winter@informatik.uni-hamburg.de> wrote:
> > Quoting Pino Toscano (2013-07-09 10:52:56)
> > > Alle martedì 9 luglio 2013, Justus Winter ha scritto:
> > > > Ignore the --nodev, --noexec and --nosuid arguments.
> > > 
> > > Why nodev? The only consumer of it seems to be sysvinit, which has been 
> > > patched to not pass nodev also on Hurd (in addition to kFreeBSD) when 
> > > mounting /proc.
> > 
> > Not as far as I can see. mountkernfs.sh contains:
> > 
> >         domount "$MNTMODE" proc "" /proc proc "-onodev,noexec,nosuid"
> > 
> > Argument #6 is CALLER_OPTS and that is not modified, so this is also
> > used on kFreeBSD.
> I have a general question here.  We used to have such "mounts" being done
> by means of passive translator settings, on /proc, for example.  It now
> appears that you're re-working this to use the "active mount command" of
> standard Unix (so, setting an active translator on /proc at each system
> boot)?  Is the passive translator setting meant to go away then?
> The same question came up in my mind already when I saw your /etc/fstab
> patches go by; currently we use /etc/fstab only for fsck purposes.
> I'm not convinced one approach is better than the other.  The passive
> translator setting was a novel feature of the Hurd, given that it has no
> direct equivalent (letting the registry in /etc/fstab aside) in Unix, and
> Debian by default is such a Unix system, so Debian GNU/Hurd -- so far --
> was different from that.  On the other hand, a passive translator setting
> also is not quite what you'd get in a persistent system (which, I guess,
> may partly have influenced this Hurd design decision?),
> <http://en.wikipedia.org/wiki/Persistence_%28computer_science%29>.  As we
> know, passive translators do have their issues, too, for example as
> described in »3.5 Passive Translators and Naming« in
> <http://www.gnu.org/software/hurd/hurd/critique.html>, or
> <http://www.gnu.org/software/hurd/open_issues/translators_set_up_by_untrusted_users.html>
> also has some discussion about passive translators.
> Is this enough to generally declare passive translators "obsolete"?

Well, I can only speak for myself, but I'm not declaring anything as
obsolete, I'm just making sure that the Debian way of configuring the
system also applies to Debian/Hurd. This includes honoring the fstab
and later on also interfaces(5). If anyone wants to use passive
translators instead, she can still do so.

That being said I do not like Hurds passive translator concept that
much. True persistence would be awesome though...

> Aside from the presumed elegancy aspect of the first approach, whether
> the "system default configuration" in /servers/ is done by means of
> passive translator settings on the respective nodes, or by active
> translators that are started at system boot based on information present
> in /etc/ configuration files, seems basically just like a detail question
> (at least when leaving the idea aside that passive translators are only
> activated on demand, and thus consume no resources by default).

It is elegant alright, but needs support from the filesystem, right?
I.e. no passive translators unless the filesystem translator has a
means of storing them. Also with respect to not using resources, that
is also true for translators that are unused and paged out, and any
process traversing the filesystem will start all passive translators,
like say updatedb.

> Is Debian GNU/Hurd going to replace all usage of passive translators with
> active ones, set at system boot, or a mixture of passive and active (by
> design), or a mixture of passive and active for the time being (because
> some things currently can't sensibly be implemented by using active
> translators only, such as the mishmash in /dev/ -- which eventually was
> meant to be replaced by a "super devfs translator", which likely will
> have issues on its own)?
> Grüße,
>  Thomas


reply via email to

[Prev in Thread] Current Thread [Next in Thread]