Hi,
After installing and running sbuild+sbuild-createchroot it failed and a
lot of passive translators? are still running at /tmp/*, e.g.
\rm -rf /tmp/*
rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/fd': Device or resource busy
rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/vcs'
Applied, thanks.
Samuel
* netfs.c (netfs_get_translator): New function.
* procfs.c (procfs_get_translator): Likewise.
* procfs.h (struct procfs_node_ops): New field get_translator.
(procfs_get_translator): New function declaration.
---
netfs.c | 11 +++
procfs.c | 12
procfs.h |6 ++
3 f
Thomas Schwinge, le Tue 09 Jul 2013 15:40:18 +0200, a écrit :
> Is the passive translator setting meant to go away then?
Nope. But concerning Debian, it'll be easier for maintenance of the
"standard" places (/proc, /tmp, etc.) to use active translators started
at root, to avoid differing too much
o 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
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?),
<htt
Hi,
> I proposed two solutions in last mail. In solution a), the translator is
> > started chrooted. So the file node, parent, and target are
> respectively:
> > /foo, /, and / in its eyes; and /chroot/foo, /chroot, and /chroot in
> > reality.
>
> > I am not sure if this translator can still ser
On 6/21/07, Neal H. Walfield <[EMAIL PROTECTED]> wrote:
> Ok, I got it. I will consider to support the file descriptor
reprentation,
> but will not implement complex semantics as redirection first.
Redirection is a shell feature. If you support the file descriptor
representation, then you can
At Thu, 21 Jun 2007 20:02:35 +0800,
Wei Shen wrote:
>
> On 6/21/07, Neal H. Walfield <[EMAIL PROTECTED]> wrote:
> >
> > At Thu, 21 Jun 2007 15:37:49 +0800,
> > > Could you please give some explanation on "PFINETSERVER=fd:3 myprog
> > > 3 >
> > From the bash manual:
> >
> > 3.6.1 Redirecting Input
On 6/21/07, Neal H. Walfield <[EMAIL PROTECTED]> wrote:
At Thu, 21 Jun 2007 15:37:49 +0800,
> Could you please give some explanation on "PFINETSERVER=fd:3 myprog
> 3
Ok, I got it. I will consider to support the file descriptor reprentation,
but will not implement complex semantics as redirecti
At Thu, 21 Jun 2007 15:37:49 +0800,
Wei Shen wrote:
>
> Hi,
>
> Could you please give some explanation on "PFINETSERVER=fd:3 myprog
> 3http://www.gnu.org/software/bash/manual/bashref.html#SEC38
So, as bash starts myprog, it opens /path/to/pfinet and inserts the
resulting file descriptor into the
Hi,
Could you please give some explanation on "PFINETSERVER=fd:3 myprog
3 wrote:
There is a bit of confusion here, I'm going to try to be more
specific, please indulge me.
Thanks!
The translator needs not to know whether a process is chrooted or not, it
> just always adds (for any process)
There is a bit of confusion here, I'm going to try to be more
specific, please indulge me.
At Thu, 21 Jun 2007 00:25:33 +0800,
Wei Shen wrote:
> The fs server or the translator?
What is an fs server? In the Hurd, translators are file systems: some
are one node file systems; and, some expose comp
13 matches
Mail list logo
