Sergey Bugaev, le sam. 08 mai 2021 14:51:22 +0300, a ecrit:
> if we failed to set the translator (either
> because of this issue, or for any other reason), let's shut the
> translator back down instead of leaving it in limbo.
We'd rather do that indeed, thanks!
Samuel
Sergey Bugaev, le sam. 08 mai 2021 14:51:22 +0300, a ecrit:
> P.S. There must be something wrong with your mailserver. I only
> received a bunch of replies form you just a few minutes ago, and
> seemingly so did the archive [0], but your citation indicates that you
> have sent the reply promptly af
On Sat, May 8, 2021 at 2:39 PM Samuel Thibault wrote:
> I pushed the revert, thanks!
Thank you!
I'm attaching another patch that tries to make settrans handle this
case a tiny bit better: if we failed to set the translator (either
because of this issue, or for any other reason), let&#x
Hello,
Sergey Bugaev, le ven. 07 mai 2021 15:41:17 +0300, a ecrit:
> I don't think I understand the reasoning behind [1]. Perhaps I'm
> missing something?
I don't see either why not deallocating it. Event if it's a dead name,
we want to deallocate it, so as to free the port name.
Samuel
Samuel Thibault, le ven. 07 mai 2021 15:29:49 +0200, a ecrit:
> Sergey Bugaev, le ven. 07 mai 2021 15:41:17 +0300, a ecrit:
> > I don't think I understand the reasoning behind [1]. Perhaps I'm
> > missing something?
>
> I don't see either why not deallocating it. Event if it's a dead name,
> we wa
Hello yet again,
I'm hitting the following issue when trying to re-set a translator on
a node whose translator has previously died:
$ settrans -acP /tmp/yes ~/dev-yes/hurd/yes
Translator pid: 1039
Pausing...
$ kill 1039
$ settrans -ag /tmp/yes ~/dev-yes/hurd/yes
settrans: /tmp/yes: (os
d
> > > and set it as NODE's active translator. This is the equivalent of
> > > doing:
> > >
> > > % settrans --active /node $(showtrans /node)
> >
> > A way to do it would be to just stat the node, but that may have other
> > consequenc
Quoting Samuel Thibault (2014-06-14 21:48:09)
> Hello,
>
> Justus Winter, le Wed 11 Jun 2014 13:41:10 +0200, a écrit :
> > Start the translator specified by the NODE's passive translator record
> > and set it as NODE's active translator. This is the equivalent of
Hello,
Justus Winter, le Wed 11 Jun 2014 13:41:10 +0200, a écrit :
> Start the translator specified by the NODE's passive translator record
> and set it as NODE's active translator. This is the equivalent of
> doing:
>
> % settrans --active /node $(showtrans /node)
A
Start the translator specified by the NODE's passive translator record
and set it as NODE's active translator. This is the equivalent of
doing:
% settrans --active /node $(showtrans /node)
* utils/settrans.c (argp_option): Add --start.
(parse_opt): Handle --start.
(main): Retrieve t
Justus Winter, le Tue 10 Dec 2013 18:08:13 +0100, a écrit :
> Previously, settrans --chroot would just exec the target. Create a
> new process for that purpose. Wait for its completion, then ask the
> translator (nicely by default) to go away. If it refuses with EBUSY,
> it migh
Justus Winter, le Tue 10 Dec 2013 17:50:26 +0100, a écrit :
> Previously, settrans --chroot would just exec the target. Create a
> new process for that purpose. Wait for its completion, then ask the
> translator (nicely by default) to go away. If it refuses with EBUSY,
> it migh
Previously, settrans --chroot would just exec the target. Create a
new process for that purpose. Wait for its completion, then ask the
translator (nicely by default) to go away. If it refuses with EBUSY,
it might be because some process has daemonized inside the chrooted
environment.
This
Previously, settrans --chroot would just exec the target. Create a
new process for that purpose. Wait for its completion, then ask the
translator (nicely by default) to go away. If it refuses with EBUSY,
it might be because some process has daemonized inside the chrooted
environment.
This
Justus Winter, le Thu 07 Nov 2013 19:12:30 +0100, a écrit :
> This switch makes settrans write the pid file of the active translator
> it starts to a file. This makes the pid easily retrievable for test
> suites.
Ack.
> * utils/settrans.c (options): Add --pid-file.
> (main
This switch makes settrans write the pid file of the active translator
it starts to a file. This makes the pid easily retrievable for test
suites.
* utils/settrans.c (options): Add --pid-file.
(main): Add variable pid_file.
(parse_opt): Handle --pid-file switch.
(open_node): Write pid file
Ludovic Courtès, le Mon 05 Mar 2012 23:36:53 +0100, a écrit :
> This patch makes sure /libexec/console-run creates and installs
> /dev/console on the first run without considering it a failure if it
> didn't exist already.
Applied with comment fix, thanks.
Samuel
This patch makes sure /libexec/console-run creates and installs
/dev/console on the first run without considering it a failure if it
didn't exist already.
* daemons/console-run.c (TERMINAL_FIRST_TRY): Change node to
`/dev/console'.
(TERMINAL_SECOND_TRY): Change node to `/tmp/console'.
(open_
Hi,
On Mon, Feb 14, 2011 at 06:00:10PM -0800, Roland McGrath wrote:
> Perhaps what would both be appropriate for --help and satisfy the
> apparent intent behind your changes, is to add a short paragraph about
> what active and passive translators are to the "doc" text after the
> \v, so it appear
Hi,
On Tue, Feb 15, 2011 at 07:02:46PM +0200, Ognyan Kulev wrote:
> Some days ago "(default)" was added for "-p". I think it'd be good if
> clarification is added that -a and -p are not mutually exclusive.
> Something like ""Set NODE's active translator. Can be combined with
> --passive."
Indeed
Hi,
On Thu, Feb 17, 2011 at 01:50:36AM +0100, Samuel Thibault wrote:
> Roland McGrath, le Tue 15 Feb 2011 19:10:34 -0800, a écrit :
> > "Start TRANSLATOR and set it as NODE's active translator" might be
> > more clear, though perhaps too long.
> Maybe simply
>
> "Start and set NODE's active tra
olafbuddenha...@gmx.net, le Mon 14 Feb 2011 08:45:42 +0100, a écrit :
> On Sat, Feb 12, 2011 at 11:01:04AM -0800, Roland McGrath wrote:
>
> > --help is not the place to describe everything about the system.
>
> Sure, but being *somewhat* more verbose certainly can't hurt...
>
> Either way, I ass
Hi,
On Sat, Feb 12, 2011 at 11:01:04AM -0800, Roland McGrath wrote:
> --help is not the place to describe everything about the system.
Sure, but being *somewhat* more verbose certainly can't hurt...
Either way, I assume a patch that adds *only* the "(default)" bit would
be uncontroversial?
-an
Roland McGrath, le Wed 16 Feb 2011 16:54:48 -0800, a écrit :
> > "Start and set NODE's active translator"
>
> That looks good.
>
> Perhaps "Change NODE's passive translator record" if you
> really want something different.
Ok, I've commited these.
Samuel
> "Start and set NODE's active translator"
That looks good.
> ? Also, for -p we might use
>
> "Record NODE's passive translator"
>
> to remind that it's merely recorded in the FS?
I again think that is more confusing rather than less.
Perhaps "Change NODE's passive translator record" if you
r
and not writing down something in the FS.
>
> That seems reasonable. Setting an active translator does not necessarily
> entail starting it, but unless there is a mode of using settrans I've
> forgotten, settrans -a does always start an active translator.
> "Start NODE&
an active translator does not necessarily
entail starting it, but unless there is a mode of using settrans I've
forgotten, settrans -a does always start an active translator.
"Start NODE's active translator" might seem to imply that it just
activates (i.e. starts) the translator
Etenil, le Tue 15 Feb 2011 17:16:36 +, a écrit :
> On 15/02/11 17:01, Roland McGrath wrote:
> >It is self-explanatory.
> >What it doesn't explain is the entire structure of the system.
I'd still be in favor or replacing "Set NODE's active translator" with
"Start NODE's active translator", to r
I'd like to point out that the usage of settrans is introduced very
early in the install process of Hurd (especially to get the network up),
and this is only given as a recipe (on the wiki for instance) without
explanation of what it actually does.
In this situation, a new user's fi
На 15.2.2011 г. 18:31 ч., Arne Babenhauserheide написа:
I disagree. settrans is the basic building block of almost everything a user
does in the Hurd (except subhurds), so it should be selfexplanatory where
possible and where it is not, --help should suffice.
Some days ago "(default)
It is self-explanatory.
What it doesn't explain is the entire structure of the system.
Hi Roland,
On Monday 14 February 2011 18:00:10 Roland McGrath wrote:
> if you don't know the basics of Hurd
> design like the definitions of active and passive translator, then
> you really don't want to be using settrans in the first place.
I disagree. settrans is the basi
appears at the bottom of the --help output. This is
still a bit pointless IMHO, since if you don't know the basics of Hurd
design like the definitions of active and passive translator, then
you really don't want to be using settrans in the first place.
Thanks,
Roland
Sorry for the double post, the attachment didn't get through the first time.
I have modified my patch following rejection. It is, I hope, less detailed
while making settrans --help less ambiguous.
Best regards,
Guillaume Pasquet
Roland McGrath wrote:
--help is not the place to des
I have modified my patch following rejection.
It is, I hope, less detailed while making settrans --help less ambiguous.
Best regards,
Guillaume Pasquet
Roland McGrath wrote:
--help is not the place to describe everything about the system.
--help is not the place to describe everything about the system.
Hi there,
I've written a trivial patch that clarifies the --help message of settrans.
The problem is that settrans can be used as:
settrans -fgap ...
Thus using both the "active" and "passive" option at the same time. This
appeared illogical.
Hope i
Hello,
this patch adds a new option to settrans: --interactive. The main use
case is to be able to start a translator under gdb like so:
settrans -i /tmp/foo gdb /hurd/hello
This is extremely useful if the translator crashes before the startup
handshake, but also just plain more convenient
Hello,
I'm going to post 2 patches that implements a new useful feature to
settrans. The first one exposes needed functionallity in libfshelp
and the second one implements the feature. More info in the patch
mails themselves.
(This is the first time I'm trying `tg mail' so plea
URL:
<http://savannah.gnu.org/bugs/?29463>
Summary: Translators output garbage when started with
settrans -P and stopped by gdb
Project: The GNU Hurd
Submitted by: hammy
Submitted on: Wed 07 Apr 2010 08:54:08 P
On Tue, 2008-06-10 at 12:59 +0400, A.Salatov wrote:
> No, you correct me if I'm wrong, but when I think about 'settrans' my
> mind always going to compare it to 'umount' and I started to think about
> a reasons why 'umount' is 'umount' and not
A.Salatov ha scritto:
No, you correct me if I'm wrong, but when I think about 'settrans' my
mind always going to compare it to 'umount' and I started to think about
a reasons why 'umount' is 'umount' and not 'unmount'.
I've al
Thomas Thurman wrote:
2008/6/9 A.Salatov <[EMAIL PROTECTED]>:
Hi,
In name of command 'settrans' is too many times used 't'. Actualy it is
used in it's name, twice. But normaly name of this command must unclude 't'
only once. So in normal form, name of
2008/6/9 A.Salatov <[EMAIL PROTECTED]>:
> Hi,
> In name of command 'settrans' is too many times used 't'. Actualy it is
> used in it's name, twice. But normaly name of this command must unclude 't'
> only once. So in normal form, name of this c
Hi,
In name of command 'settrans' is too many times used 't'. Actualy it is
used in it's name, twice. But normaly name of this command must unclude
't' only once. So in normal form, name of this command, must be such:
'setrans'. In general it is a minor bug, but it is bug. ;-)
mary: gdb attach to settrans -aP ext2fs triggers assertion
Original Submission: Summarised:
[vt1] $ settrans /mnt /hurd/ext2fs /dev/hd0s3
...pid 100
Pause...
[vt2] $ gdb /hurd/ext2fs 100
(gdb) break read_node
(gdb) continue
[vt1] (press Enter)
libdiskfs/init-sta
> On Sat, May 04, 2002 at 06:58:59PM -0400, Roland McGrath wrote:
> > I suspect that presently if you use this (assuming settrans works right),
> > that the filesystem process will stick around after the command finishes
> > and you might have to kill it.
>
> I
On Sat, May 04, 2002 at 06:58:59PM -0400, Roland McGrath wrote:
> I suspect that presently if you use this (assuming settrans works right),
> that the filesystem process will stick around after the command finishes
> and you might have to kill it.
Indeed, this is what happens.
> If
Hi!
The below patch adds the new --chroot option to the documentation of
settrans. (The wording is mostly taken from Roland's original mail.)
Cheers,
GNU/Wolfgang
2002-05-07 Wolfgang Jährling <[EMAIL PROTECTED]>
* hurd.texi (Invoking settrans): Document new --ch
I've added a new mode of operation to the settrans command, in the form of
the new option --chroot. I have not tested this code, so please try it out
for me.
settrans --chroot is a way to start a filesystem translator that need not
be attached to any parent filesystem node as an a
On Fri, Jun 29, 2001 at 01:31:41PM +0200, Marcus Brinkmann wrote:
> Funny, isn't it ;)
Yes it is! :)
> Yes, but maybe a different one than you think. What about the following:
>
> $ dd if=/dev/zero of=/image bs=1024k count=10
> $ mke2fs /image
> $ settrans -a /h
On Fri, Jun 29, 2001 at 09:31:08PM +0200, Maurizio Boriani wrote:
> Hi all,
> for a mistake I launched this on command line:
> elisia# settrans -a /home /hurd/ext2fs /home
>
> and then try to enter in /home using cd. I looped out.
Funny, isn't it ;)
> I think th
Hi all,
for a mistake I launched this on command line:
elisia# settrans -a /home /hurd/ext2fs /home
and then try to enter in /home using cd. I looped out. Unfortunly I was not using
screen and I must reboot my laptop.
I think this could be a bug, a check on source device and mounting
> libnetfs needs the change too.
Opps.
libnetfs/ChangeLog:
2001-06-15 Neal H Walfield <[EMAIL PROTECTED]>
* file-set-translator.c (netfs_S_file_set_translator): If
FS_TRANS_ORPHAN is set, do not ask the active translator to go
away, just disconnect it.
Ind
libnetfs needs the change too.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Great! I've checked in your changes.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
new flag
> FS_TRANS_ORPHAN, and the settrans option --orphan (perhaps
> --detach-old-translator as an alias). I think the "orphaned child
> filesystem" metaphor stands up, as I imagine that children become orphans
> unceremoniously by finding themselves suddenly unable to find
Roland McGrath <[EMAIL PROTECTED]> writes:
> I agree with Neal that a FS_TRANS_* flag is more appropriate--that leaves
> goaway_flags as purely flags passed on to the fsys_goaway RPC, which is a
> clear and easy thing to understand.
Yes, agreed, this is better than as a goaway flag. It should
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > I have no objection to adding a flag for file_set_translator to avoid
> > sending the goaway. But calling the flag "disconnect" is wrong: a
> > disconnect happens whether you set that flag or not.
>
> I fail to see how this is true: if the transla
new flag
> FS_TRANS_ORPHAN, and the settrans option --orphan (perhaps
> --detach-old-translator as an alias). I think the "orphaned child
> filesystem" metaphor stands up, as I imagine that children become orphans
> unceremoniously by finding themselves suddenly unable to find
I agree with Neal that a FS_TRANS_* flag is more appropriate--that leaves
goaway_flags as purely flags passed on to the fsys_goaway RPC, which is a
clear and easy thing to understand. I think we should call the new flag
FS_TRANS_ORPHAN, and the settrans option --orphan (perhaps
--detach-old
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > As for the shell command settrans, I think that -f should timeout, and
> > if nothing happens then repeat the call with the new flag attached.
> > Perhaps there should be a new flag with the current meaning of -f
> &g
S_DISCONNECT and be or'ed into the active flags rather than the
goaway flags.
> As for the shell command settrans, I think that -f should timeout, and
> if nothing happens then repeat the call with the new flag attached.
> Perhaps there should be a new flag with the current meaning o
ribes what the option requests.
As for the shell command settrans, I think that -f should timeout, and
if nothing happens then repeat the call with the new flag attached.
Perhaps there should be a new flag with the current meaning of -f
(that is, set the FORCE bit, but don't bypass the
ke `--detach' a little better, because it carries the implication
that the filesystem server is left intact, but is dropped from the
node.
Would it help make things clearer to think about what the semantics of
`settrans -fg --detach' are?
[As an aside, thanks for doing this, Neal. It'll
t; go away nicely, and if that fails, disconnect it anyway.
>
> Using a regular goaway (i.e. `settrans -g node') asks the filesystem to
> send an fsys_goaway to the child. Appling the force options adds
> FSYS_GOAWAY_FORCE to the flags passed to the child. Normally, this
> option
get the translator
> disappear. In this case, it should probably try to make the translator
> go away nicely, and if that fails, disconnect it anyway.
Using a regular goaway (i.e. `settrans -g node') asks the filesystem to
send an fsys_goaway to the child. Appling the force options adds
F
Neal H Walfield <[EMAIL PROTECTED]> writes:
>{"recursive", 'R', 0, 0, "Shutdown its children too"},
>{"force", 'f', 0, 0, "If it doesn't want to die, force it"},
>{"nosync", 'S', 0, 0, "Don't sync it before killing it"},
> + {"disconnect", 'd', 0, 0, "Disconnect the tra
> Your code does nothing to either translator setting, but just sends an
> fsys_goaway to the active translator. This leaves it up to the translator
> to die or not as it chooses. The file_set_translator RPC that will be made
> by "settrans -a FILE" to the parent files
On Sat, Mar 31, 2001 at 11:46:45PM -0500, Roland McGrath wrote:
> I don't understand what your option is supposed to do.
After looking at the code some more, my code adds nothing.
PGP signature
I don't understand what your option is supposed to do.
With -a and but no -p, regardless of the other options, settrans
will not affect the passive translator. The file_set_translator
RPC affects either passive or active or both, according to the flags
arguments.
Your code does nothi
This patch was inspired by the TODO item:
** settrans:
*** needs an option to make the active go away without using goaway. !
Note that I choose `-l' (i.e. leave passive translator) for lack of
a more fitting letter.
2001-03-29 Neal H Walfield <[EMAIL PROTECTED]>
* sett
> Sorry, I assumed that it was a mistake was in my code; Should I report
> it to the gdb people?
Well, the "gdb people" for the Hurd is Mark.
> Here is what gdb said:
> (gdb) p _hurd_init
> _hurd_init _hurd_init_dtable _hurd_init_dtablesize
See, I told you I got the name wrong.
On Wed, Jan 24, 2001 at 02:33:53AM -0500, Roland McGrath wrote:
> > > First, please check whether the scenario you are trying does or doesn't
> > > exhibit the same bug in a vanilla system without your changes.
> >
> > The exact same error.
>
> Well, you certainly could have saved some wild goo
> > First, please check whether the scenario you are trying does or doesn't
> > exhibit the same bug in a vanilla system without your changes.
>
> The exact same error.
Well, you certainly could have saved some wild goose chases by making that
clear in the first place.
> It is blocked in the c
a vanilla system without your changes.
The exact same error.
> Next, here are some things to try. When you attach gdb, look around at the
> state before giving settrans any input. See exactly what is going on in
> the filesystem. It ought to be blocked in diskfs_startup_diskfs'
gdb, look around at the
state before giving settrans any input. See exactly what is going on in
the filesystem. It ought to be blocked in diskfs_startup_diskfs's call to
the fsys_startup RPC. The process state of the filesystem ought to be
completely set up at that point (before main was ca
g. in gdb or the proc
> server?
Here is (hopefully) a clearer presentation of the problem.
After adding the aforementioned code to a clean tree, translators fail
to retreive their port to the proc server if one attaches to the
translator with gdb _during_ the pause.
Here are the different scen
On Wed, Jan 17, 2001 at 06:21:40PM -0500, Roland McGrath wrote:
> I don't see anything obviously wrong (other than your spelling of "semantics").
Do you think it might be an error elsewhere, e.g. in gdb or the proc
server?
PGP signature
I don't see anything obviously wrong (other than your spelling of "semantics").
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
mach_msg_type_name_t *underlying_type,
+task_t task, void *cookie)
{
node = file_name_lookup (fs->mntent.mnt_dir,
flags | O_NOTRANS, 0666);
@@ -331,7 +332,7 @@
/* Now we have a translator com
I have modified fshelp_start_translator_long to pass the task port for
the translator to the call back function. This works fine if a debugger
is no attached to either the translator or the settrans. When I do, the
translator gets MACH_PORT_NULL when it does a getport call. Here is
some output
82 matches
Mail list logo
