df triggering deallocation of an invalid port?
Hi! The root filesystem and the one backing ~/ are two separate instances of ext2fs. I just ran »dh -h ~/« , and noticed on the GNU Mach console: »task e19b6e10 deallocating an invalid port 1047, most probably a bug.« As it is one of the few Mach tasks that don't get a proper name set (as far as I know), I suspect it is the root filesystem that has been printing this. Running df again, it does not reproduce. (But I've seen this before, so probably once per system boot.) Per rpctrace, df is doing all kinds of RPCs. Issue to be confirmed, and to be analyzed. Grüße, Thomas pgpyWWO2o8fls.pgp Description: PGP signature
[PATCH] exec: add proper argument parsing, add --device-master-port
If the device master port is given, a boot-time exec server can print
diagnostic messages earlier.
* exec/main.c (opt_device_master): New variable.
(OPT_DEVICE_MASTER_PORT): New macro.
(options): New set of options.
(parse_opt): New function.
(trivfs_append_args): Likewise.
(argp): Pull the argp definition out of main.
(trivfs_runtime_argp): Set, so that we respond properly to fsysopts.
(open_console): Pull the code out of S_exec_init and generalize it.
(main): Call open_console if a device master port is given.
(S_exec_init): Call open_console.
---
exec/main.c | 106
1 file changed, 93 insertions(+), 13 deletions(-)
diff --git a/exec/main.c b/exec/main.c
index 78faebd..784000b 100644
--- a/exec/main.c
+++ b/exec/main.c
@@ -45,6 +45,7 @@ int trivfs_cntl_nportclasses = 1;
struct trivfs_control *fsys;
char **save_argv;
+mach_port_t opt_device_master;
#include exec_S.h
@@ -104,16 +105,104 @@ deadboot (void *p)
ports_enable_class (trivfs_cntl_portclasses[0]);
}
+#define OPT_DEVICE_MASTER_PORT (-1)
+
+static const struct argp_option options[] =
+{
+ {device-master-port, OPT_DEVICE_MASTER_PORT, PORT, 0,
+ If specified, a boot-time exec server can print
+ diagnostic messages earlier., 0},
+ {0}
+};
+
+static error_t
+parse_opt (int opt, char *arg, struct argp_state *state)
+{
+ switch (opt)
+{
+default:
+ return ARGP_ERR_UNKNOWN;
+case ARGP_KEY_INIT:
+case ARGP_KEY_SUCCESS:
+case ARGP_KEY_ERROR:
+ break;
+
+case OPT_DEVICE_MASTER_PORT:
+ opt_device_master = atoi (arg);
+ break;
+}
+ return 0;
+}
+
+/* This will be called from libtrivfs to help construct the answer
+ to an fsys_get_options RPC. */
+error_t
+trivfs_append_args (struct trivfs_control *fsys,
+ char **argz, size_t *argz_len)
+{
+ error_t err = 0;
+ char *opt;
+
+ if (MACH_PORT_VALID (opt_device_master))
+{
+ asprintf (opt, --device-master-port=%d, opt_device_master);
+
+ if (opt)
+ {
+ err = argz_add (argz, argz_len, opt);
+ free (opt);
+ }
+}
+
+ return err;
+}
+
+static struct argp argp =
+{ options, parse_opt, 0, Hurd standard exec server. };
+
+/* Setting this variable makes libtrivfs use our argp to
+ parse options passed in an fsys_set_options RPC. */
+struct argp *trivfs_runtime_argp = argp;
+
+/* Get our stderr set up to print on the console, in case we have to
+ panic or something. */
+error_t
+open_console (mach_port_t device_master)
+{
+ static int got_console = 0;
+ mach_port_t cons;
+ error_t err;
+
+ if (got_console)
+return 0;
+
+ err = device_open (device_master, D_READ|D_WRITE, console, cons);
+ if (err)
+return err;
+
+ stdin = mach_open_devstream (cons, r);
+ stdout = stderr = mach_open_devstream (cons, w);
+
+ got_console = 1;
+ mach_port_deallocate (mach_task_self (), cons);
+ return 0;
+}
int
main (int argc, char **argv)
{
error_t err;
mach_port_t bootstrap;
- struct argp argp = { 0, 0, 0, Hurd standard exec server. };
argp_parse (argp, argc, argv, 0, 0, 0);
+ if (MACH_PORT_VALID (opt_device_master))
+{
+ err = open_console (opt_device_master);
+ assert_perror (err);
+ mach_port_deallocate (mach_task_self (), opt_device_master);
+}
+
save_argv = argv;
task_get_bootstrap_port (mach_task_self (), bootstrap);
@@ -236,18 +325,9 @@ S_exec_init (struct trivfs_protid *protid,
err = get_privileged_ports (host_priv, device_master);
assert_perror (err);
- {
-/* Get our stderr set up to print on the console, in case we have
- to panic or something. */
-mach_port_t cons;
-error_t err;
-err = device_open (device_master, D_READ|D_WRITE, console, cons);
-assert_perror (err);
-mach_port_deallocate (mach_task_self (), device_master);
-stdin = mach_open_devstream (cons, r);
-stdout = stderr = mach_open_devstream (cons, w);
-mach_port_deallocate (mach_task_self (), cons);
- }
+ err = open_console (device_master);
+ assert_perror (err);
+ mach_port_deallocate (mach_task_self (), device_master);
proc_register_version (procserver, host_priv, exec, , HURD_VERSION);
--
2.1.0
Re: df triggering deallocation of an invalid port?
Hey Thomas :) Quoting Thomas Schwinge (2014-09-23 12:26:01) Hi! The root filesystem and the one backing ~/ are two separate instances of ext2fs. I just ran »dh -h ~/« , and noticed on the GNU Mach console: »task e19b6e10 deallocating an invalid port 1047, most probably a bug.« As it is one of the few Mach tasks that don't get a proper name set (as far as I know), Only if your gnumach is oldish, 4e55e562 sets the name of tasks created by the boot script. I do not know whether Samuel pulled this into the Debian package though. I suspect it is the root filesystem that has been printing this. I see quite a lot of tasks without proper names, I suspect fork w/o exec... Running df again, it does not reproduce. (But I've seen this before, so probably once per system boot.) Per rpctrace, df is doing all kinds of RPCs. Issue to be confirmed, and to be analyzed. Try rpctracing `/hurd/mtab /' instead of doing df. Cheers, Justus
Release process rolling new releases
Hi Thomas, hi Samuel :) I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. Thanks, Justus
Re: Release process rolling new releases
Hi! On Tue, 23 Sep 2014 16:19:02 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. The (technical) release process is not the problem; that I can do any time. For me, the question rather is, what constitutes the releases that we publish? Some new, exciting features (including considerable bug fixing, code re-writes, re-factoring, and so on), on the one hand, or regular time-based releases on the other (for example, annually). The former has the process that the new features are added, and then there is a stabilization period where only bug fixes go in, then the release is made, and the latter is basically just a snapshot of the repository at a more or less random date. Due to lack of manpower to maintain a proper release process, I see us more on the side of doing snapshots, which we can do any time we like. Now is a good time, you say? (I'm not disagreeing -- the previous release having been one year ago.) Given this, and with our last Hurd release having been 0.5, what would the next version be? 0.5.1? 0.6? Or, make it obvious that it is just a snapshot, and thus call that GNU Hurd 20140923 or similar? Grüße, Thomas pgpbR8NwZMqCe.pgp Description: PGP signature
Re: Release process rolling new releases
On Tue, Sep 23, 2014 at 05:09:30PM +0200, Thomas Schwinge wrote: For me, the question rather is, what constitutes the releases that we publish? Some new, exciting features (including considerable bug fixing, code re-writes, re-factoring, and so on), on the one hand, or regular time-based releases on the other (for example, annually). The former has the process that the new features are added, and then there is a stabilization period where only bug fixes go in, then the release is made, and the latter is basically just a snapshot of the repository at a more or less random date. Due to lack of manpower to maintain a proper release process, I see us more on the side of doing snapshots, which we can do any time we like. Now is a good time, you say? (I'm not disagreeing -- the previous release having been one year ago.) Given this, and with our last Hurd release having been 0.5, what would the next version be? 0.5.1? 0.6? Or, make it obvious that it is just a snapshot, and thus call that GNU Hurd 20140923 or similar? I suggest time-based releases, using a 0.x scheme (until the major number can be bumped to 1), so a 0.6 release. These would be snapshots of the repositories, and 0.x.y releases would include bug fixes, probably based on demand, for highly annoying bugs. As mentioned, one release every 6-to-12 months should be enough. The goal here is merely to provide specific points in time that others can base their work on (the Nix-based distribution comes to mind). -- Richard Braun
Re: Release process rolling new releases
Quoting Richard Braun (2014-09-23 17:23:49) On Tue, Sep 23, 2014 at 05:09:30PM +0200, Thomas Schwinge wrote: For me, the question rather is, what constitutes the releases that we publish? Some new, exciting features (including considerable bug fixing, code re-writes, re-factoring, and so on), on the one hand, or regular time-based releases on the other (for example, annually). The former has the process that the new features are added, and then there is a stabilization period where only bug fixes go in, then the release is made, and the latter is basically just a snapshot of the repository at a more or less random date. Due to lack of manpower to maintain a proper release process, I see us more on the side of doing snapshots, which we can do any time we like. Now is a good time, you say? (I'm not disagreeing -- the previous release having been one year ago.) Given this, and with our last Hurd release having been 0.5, what would the next version be? 0.5.1? 0.6? Or, make it obvious that it is just a snapshot, and thus call that GNU Hurd 20140923 or similar? I suggest time-based releases, using a 0.x scheme (until the major number can be bumped to 1), so a 0.6 release. These would be snapshots of the repositories, and 0.x.y releases would include bug fixes, probably based on demand, for highly annoying bugs. As mentioned, one release every 6-to-12 months should be enough. The goal here is merely to provide specific points in time that others can base their work on (the Nix-based distribution comes to mind). My thoughts exactly. I'll propose updates for the NEWS files. Justus
Re: Release process rolling new releases
Justus Winter 4win...@informatik.uni-hamburg.de skribis: I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. Excellent initiative! It would be ideal (but maybe I’m asking for too much) if this would come with a libc tarball as well, presumably based on the sv.gnu.org repo rebased on the latest libc released. In the short term that would be helpful for Guix, and in the longer term that would help the project as a whole I think. Thanks, Ludo’.
Re: Release process rolling new releases
I would think that an annual release, or a release every 2 years, coupled with a snapshot every 2 month, would be the best for most people. On Tue, Sep 23, 2014 at 1:15 PM, Ludovic Courtès l...@gnu.org wrote: Justus Winter 4win...@informatik.uni-hamburg.de skribis: I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. Excellent initiative! It would be ideal (but maybe I’m asking for too much) if this would come with a libc tarball as well, presumably based on the sv.gnu.org repo rebased on the latest libc released. In the short term that would be helpful for Guix, and in the longer term that would help the project as a whole I think. Thanks, Ludo’.
