Re: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff
Indeed, few of the patches at http://patch-tracker.debian.org/package/hurd/1:0.5.git20140326-1 look Debian-specific. For features that are not “fully baked” yet, like DDE, wouldn’t it make sense to have a branch in the Hurd repo, instead of a set of patches in Debian? As for patches for which review “never completed”, there should really be a timeout IMO, and the patch should be either rejected for everyone (including Debian), or accepted, or amended. My 2¢, Ludo’.
Re: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff
Ludovic Courtès, le Sun 06 Apr 2014 22:44:12 +0200, a écrit : Indeed, few of the patches at http://patch-tracker.debian.org/package/hurd/1:0.5.git20140326-1 look Debian-specific. For features that are not “fully baked” yet, like DDE, wouldn’t it make sense to have a branch in the Hurd repo, instead of a set of patches in Debian? Well, it's *already* a branch, in the incubator. There are some patches over that branch which lie in the Debian, which I haven't applied to the incubator because they make our DDE copy diverge even more from what was taken directly from upstream, while we'd like at some point to just push them upstream so they can profit everybody, but upstream has not really opened still. As for patches for which review “never completed”, there should really be a timeout IMO, and the patch should be either rejected for everyone (including Debian), or accepted, or amended. It's a matter of doing it, yes. Samuel
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
Put yet another way, if you ask me why isn't foo done? I'll most probably just answer because I haven't had time to do it, and nobody else took the time to do it. If you ask me could foo be done then?, I'll answer sure, patch welcome. If you ask me I've had a look, we could just apply this patch, move that, do this, and then we get foo done, then the time for me to actually do it becomes almost zero, and thus I'll happily do it. Yes, it means spending time on how to do it, but if nobody else spends it, I'll have to do it, but god knows when I'll find time to do it among all other urging matters. Samuel
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
On Mon, Apr 7, 2014 at 4:52 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: Put yet another way, if you ask me why isn't foo done? I'll most probably just answer because I haven't had time to do it, and nobody else took the time to do it. If you ask me could foo be done then?, I'll answer sure, patch welcome. If you ask me I've had a look, we could just apply this patch, move that, do this, and then we get foo done, then the time for me to actually do it becomes almost zero, and thus I'll happily do it. Yes, it means spending time on how to do it, but if nobody else spends it, I'll have to do it, but god knows when I'll find time to do it among all other urging matters. It's a time matter, and have improve space, I can understand how this is a challenging work to merge and adjust so much patches and the branches. The one who do this need have the full plan, and the big picture in the head, and done one by one carefully and leader by the initial big picture, hard as big refactor. we may need some level of frozen, to make this work easy if it's very important. The patch review mode maybe not suitable for this work, it's not minor improve. How about we make a upstream branch and do fast iterator merge and other stuff, we review this branch but not the patches, when it's OK, merge the branch to the main upstream branch or just use it as the main upstream branch? Thanks Cong Zhang
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : The one who do this need have the full plan, I don't see why one would need a full plan. A patch deals with just part of the code, you don't need to know *all* the code to review the patch, ping people about what is wrong with it, clean it, etc. How about we make a upstream branch and do fast iterator merge and other stuff, we review this branch but not the patches, when it's OK, merge the branch to the main upstream branch or just use it as the main upstream branch? Be it a branch or patches lying in Debian package is just the same. See DDE, it *is* a branch already. But if nobody works on it, well things don't happen magically, it's as simple as that :) Samuel
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit : Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : The one who do this need have the full plan, I don't see why one would need a full plan. Putting it another way, I don't think anybody has the full plan. Which is fine, all medium-to-big projects are like that. Samuel
Re: Upstreaming patches
Quoting Samuel Thibault (2014-04-07 01:02:56) This has caused me so much pain. And I imagine it is even worse for new developers. I fully understand all that, it's not fun for me either, and I'd really love to find the time to fix all that. But for now apparently only I have taken the time to dive into Zheng Da's work on DDE, so it doesn't help. We could as well just commit what is there since it's relatively split appart in the source, so it at least doesn't put ugly hacks into other directories. But it really needs some polishing in the end. As I said, for me it was also a matter of visibility and awareness. If the dde stuff would have been in the main repo, I would have applied all the cleanups and ipc improvements I've done to every other Hurd component. I would have found problems with the clang static analyzer runs, and I would have found stuff by just doing git grep. As for the two other stuff in the Debian hurd package (random, procfs), yes it is a ugly hack, and I'd rather avoid it. It was just a way to get working /dev/random and /proc so people can ran a debian system at all. Of course we should think about just merging them into the main repository, or build them another way, etc. I for myself have never found the time to even just think about it. Yes please. I never understood why those are in separate repositories. I end up spending my time mostly fixing pushing more-or-less-baked patches to Debian packages, so people at least get to try them, but the polishing+submitting work is much more work, and if nobody gives help there, well things can only go slowly for sure. There's a question of priority. For instance, should have I spent my time the other day on DDE / exec_filename / pushing some glibc patches upstream, or on fixing the pthread_condattr_setclock() so glib2.0 can continue working at all? Maybe I should just not do this kind of ugly pushing, so Debian doesn't get them, and thus people would have to really push their changes in properly, and not be happy with just seeing them applied to Debian. In the end, I'd essentially say Patch Thankfully Welcome, like they do so often on the cygwin mailing list. Well, the patches are there. The exec_filename_* series has been proposed two times, by Emilio in 2010, and then by Jeremie in 2011. The second posting didn't even receive a single reply. What else can one do? Of course, that means baked patches, which is quite some work, but the Hurd project is no exception to this requirement. I don't buy it. I do not believe in getting it right from the beginning, I believe in incremental refinement. Also, all software is crap and the Hurd is unfortunately no exception to this rule. For example, the server side rpc handling code did not follow the best practices described by the 'Mach 3 Server Writer's Guide'. Sure, it would have been awesome if everyone got that right from the start, but they didn't. And still I'm glad that the code made it into the Hurd codebase nonetheless, because otherwise there wouldn't be any Hurd server at all. If some discussion died just because a patch was not reviewed, then it's a matter of reviving it. I happen to have dozens of mails in my hurd inbox, I've just never found the time to revive their discussion. If nobody else helps on that, it'll continue getting dust. Yes, it's a matter of manpower, agreed. But... Put another way, please people just dive into patches, check why they are not upstream (just ask if it's not written in there), and have a look at how to fix that. I don't think there is anything strongly blocking anywhere, it's just a matter of doing things, so that things get done... ... I disagree here. If I start developing for a new project, the first thing I do is clone the repo and build it. Doing that for Hurd results in a broken system. That surely has the potential to scare away potential contributors, and I cannot blame them a bit. I believe that it is essential to reduce every bit of overhead possible from the development process. Developing software is hard enough as it is. If I (and you, and everyone) needs to burn time and energy on building the software, needlessly, just because the process is so rough, then this is detrimental to the project. Justus
Re: Upstreaming patches
Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit : I believe that it is essential to reduce every bit of overhead possible from the development process. Again, I fully understand that. It just happens that I spend mostly all of my available time doing: - fix the few bits without which the system is not running at all - pushing things as you say, or at least fix them so they actually work, so the Hurd can be exciting (restartable netdde, httpfs, etc.) What can I do more? If nobody helps with it, I can't invent time. Really, I don't know what to do than telling people yes, I know, but I already don't have enough time to fix it all, please help. Samuel
Re: Upstreaming patches
Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit : Quoting Samuel Thibault (2014-04-07 01:02:56) As for the two other stuff in the Debian hurd package (random, procfs), yes it is a ugly hack, and I'd rather avoid it. It was just a way to get working /dev/random and /proc so people can ran a debian system at all. Of course we should think about just merging them into the main repository, or build them another way, etc. I for myself have never found the time to even just think about it. Yes please. That is not actually answering the issue. I probably expressed myself wrong: by we should think about, I just mean somebody posting on the list about it, exposing the pros and cons, wait for settlement about the issue, and then if the cons are fine, say Ok, let's do it. And then I'll just do it and the thing will be done. I just happen not to have time to do the first part myself, just the last part. Samuel
Re: Upstreaming patches
Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit : I end up spending my time mostly fixing pushing more-or-less-baked patches to Debian packages, so people at least get to try them, but the polishing+submitting work is much more work, and if nobody gives help there, well things can only go slowly for sure. There's a question of priority. For instance, should have I spent my time the other day on DDE / exec_filename / pushing some glibc patches upstream, or on fixing the pthread_condattr_setclock() so glib2.0 can continue working at all? Maybe I should just not do this kind of ugly pushing, so Debian doesn't get them, and thus people would have to really push their changes in properly, and not be happy with just seeing them applied to Debian. In the end, I'd essentially say Patch Thankfully Welcome, like they do so often on the cygwin mailing list. Well, the patches are there. The exec_filename_* series has been proposed two times, by Emilio in 2010, and then by Jeremie in 2011. The second posting didn't even receive a single reply. What else can one do? Probably understand that Roland wasn't talking about the patch, but the principle, and thus just reposting the patches as they are will not get any better answer, so rather discuss explicitly with Roland about the exact concern he raised (usefulness of the patch, apparently). Of course, that means baked patches, which is quite some work, but the Hurd project is no exception to this requirement. I don't buy it. I do not believe in getting it right from the beginning, I believe in incremental refinement. I fully agree. But we can't really commit patches which don't even explain what they are doing and why. I'm not saying all patches are like that, but a lot of them are. Also, the more crap you accept, the more tedious it becomes to maintain it too. The DDE thing was really a big mess, it couldn't be commited as such at all. Perhaps now it can, one has to check. Up to now I have always been pressed my more urging matters. Put another way, please people just dive into patches, check why they are not upstream (just ask if it's not written in there), and have a look at how to fix that. I don't think there is anything strongly blocking anywhere, it's just a matter of doing things, so that things get done... ... I disagree here. If I start developing for a new project, the first thing I do is clone the repo and build it. Doing that for Hurd results in a broken system. That surely has the potential to scare away potential contributors, and I cannot blame them a bit. Sure, again I FULLY agree. And what is the solution? I *DONT* have the time to fix it all myself. It's as simple as that. What can I do more about it? Samuel
[PATCH] libports: fix notify_port_t receiver lookups
* libports/Makefile (MIGSFLAGS): Include mig-mutate.h.
* libports/mig-decls.h: New file.
* libports/mig-mutate.h: Likewise.
* libports/notify-dead-name.c: Fix receiver lookups.
* libports/notify-no-senders.c: Likewise.
* libports/notify-msg-accepted.c: Adjust function declaration.
* libports/notify-port-deleted.c: Likewise.
* libports/notify-port-destroyed.c: Likewise.
* libports/notify-send-once.c: Likewise.
* libports/ports.h: Likewise.
* proc/Makefile (MIGSFLAGS): Include mig-mutate.h, move PROCESS mutators...
* proc/mig-mutate.h: ... into a new file, add NOTIFY mutators.
* proc/notify.c: Fix receiver lookups, adjust function declarations.
* term/devio.c (ports_do_mach_notify_send_once): Adjust accordingly.
---
libports/Makefile| 1 +
libports/mig-decls.h | 40
libports/mig-mutate.h| 25 +
libports/notify-dead-name.c | 5 ++---
libports/notify-msg-accepted.c | 3 ++-
libports/notify-no-senders.c | 5 ++---
libports/notify-port-deleted.c | 3 ++-
libports/notify-port-destroyed.c | 3 ++-
libports/notify-send-once.c | 2 +-
libports/ports.h | 20 ++--
proc/Makefile| 4 +---
proc/mig-mutate.h| 33 +
proc/notify.c| 24
term/devio.c | 6 +++---
14 files changed, 140 insertions(+), 34 deletions(-)
create mode 100644 libports/mig-decls.h
create mode 100644 libports/mig-mutate.h
create mode 100644 proc/mig-mutate.h
diff --git a/libports/Makefile b/libports/Makefile
index 767ee73..30da1c1 100644
--- a/libports/Makefile
+++ b/libports/Makefile
@@ -45,5 +45,6 @@ LDLIBS += -lpthread
OBJS = $(SRCS:.c=.o) notifyServer.o interruptServer.o
MIGCOMSFLAGS = -prefix ports_
+MIGSFLAGS = -imacros $(srcdir)/mig-mutate.h
include ../Makeconf
diff --git a/libports/mig-decls.h b/libports/mig-decls.h
new file mode 100644
index 000..f8c4f15
--- /dev/null
+++ b/libports/mig-decls.h
@@ -0,0 +1,40 @@
+/*
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ Written by Justus Winter.
+
+ This file is part of the GNU Hurd.
+
+ The GNU Hurd is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2, or (at
+ your option) any later version.
+
+ The GNU Hurd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with the GNU Hurd. If not, see http://www.gnu.org/licenses/. */
+
+#ifndef __LIBPORTS_MIG_DECLS_H__
+#define __LIBPORTS_MIG_DECLS_H__
+
+#include ports.h
+
+/* Called by server stub functions. */
+
+static inline struct port_info * __attribute__ ((unused))
+begin_using_port_info_port (mach_port_t port)
+{
+ return ports_lookup_port (0, port, 0);
+}
+
+static inline void __attribute__ ((unused))
+end_using_port_info (struct port_info *p)
+{
+ if (p)
+ports_port_deref (p);
+}
+
+#endif /* __LIBPORTS_MIG_DECLS_H__ */
diff --git a/libports/mig-mutate.h b/libports/mig-mutate.h
new file mode 100644
index 000..f692236
--- /dev/null
+++ b/libports/mig-mutate.h
@@ -0,0 +1,25 @@
+/*
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ Written by Justus Winter.
+
+ This file is part of the GNU Hurd.
+
+ The GNU Hurd is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2, or (at
+ your option) any later version.
+
+ The GNU Hurd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with the GNU Hurd. If not, see http://www.gnu.org/licenses/. */
+
+#define NOTIFY_INTRAN \
+ port_info_t begin_using_port_info_port (mach_port_t)
+#define NOTIFY_DESTRUCTOR \
+ end_using_port_info (port_info_t)
+#define NOTIFY_IMPORTS \
+ import libports/mig-decls.h;
diff --git a/libports/notify-dead-name.c b/libports/notify-dead-name.c
index c67145d..f974e33 100644
--- a/libports/notify-dead-name.c
+++ b/libports/notify-dead-name.c
@@ -22,13 +22,12 @@
#include notify_S.h
error_t
-ports_do_mach_notify_dead_name (mach_port_t notify, mach_port_t dead_name)
+ports_do_mach_notify_dead_name (struct port_info *pi,
+
Please merge procfs into the Hurd repository
Dear maintainer :) please merge procfs (found in [0]) into the main Hurd repository. 0: git://git.sv.gnu.org/hurd/procfs.git Rationale: The procfs translator provides a Linux-compatible /proc filesystem. While there is no standard that defines the /proc filesystem, a lot of software depends on this. Having a /proc filesystem thus enables more software to run on the Hurd. The procfs has been tested in Debian/Hurd for quite some time now. I consider it essential for any Hurd distribution. Pros: Integrating it into the main repository ... * ... gives it a broader exposure to reviews, cleanups, and static analysis. * ... makes large-scale changes to the Hurd base easier. The procfs translator depends on the API and most likely even internal implementational details of the core Hurd libraries. * ... makes packaging the Hurd easier for Debian/Hurd and any other potential distributions. Thanks for considering, Justus
[PATCH] libports: fix notify_port_t receiver lookups
This is a patch that in conjunction with
e9687ec4ff525ae4a88314ba4ae97da770bd012f fixes the receiver lookups
for the notify_port_t type.
* devnode/Makefile (MIGSFLAGS): Use mig-mutate.h.
* eth-filter/Makefile: Likewise.
* eth-multiplexer/Makefile: Likewise.
* libmachdev/Makefile: Likewise.
* devnode/mig-mutate.h: New file.
* eth-filter/mig-mutate.h: Likewise.
* eth-multiplexer/mig-mutate.h: Likewise.
* libmachdev/mig-mutate.h: Likewise.
* devnode/devnode.c: Adjust accordingly.
* eth-filter/filter.c: Likewise.
* eth-multiplexer/notify_impl.c: Likewise.
* libmachdev/trivfs_server.c: Likewise.
---
devnode/Makefile | 1 +
devnode/devnode.c | 14 +++---
devnode/mig-mutate.h | 25 +
eth-filter/Makefile | 1 +
eth-filter/filter.c | 14 +++---
eth-filter/mig-mutate.h | 25 +
eth-multiplexer/Makefile | 1 +
eth-multiplexer/mig-mutate.h | 25 +
eth-multiplexer/notify_impl.c | 14 +++---
libmachdev/Makefile | 1 +
libmachdev/mig-mutate.h | 25 +
libmachdev/trivfs_server.c| 14 +++---
12 files changed, 132 insertions(+), 28 deletions(-)
create mode 100644 devnode/mig-mutate.h
create mode 100644 eth-filter/mig-mutate.h
create mode 100644 eth-multiplexer/mig-mutate.h
create mode 100644 libmachdev/mig-mutate.h
diff --git a/devnode/Makefile b/devnode/Makefile
index f452256..2c8af58 100644
--- a/devnode/Makefile
+++ b/devnode/Makefile
@@ -24,6 +24,7 @@ DIST_FILES = ourdevice.defs notify.defs
HURDLIBS = ports trivfs fshelp shouldbeinlibc
target = devnode
MIGSTUBS = ourdeviceServer.o notifyServer.o
+MIGSFLAGS = -imacros $(srcdir)/mig-mutate.h
OBJS = $(SRCS:.c=.o) $(MIGSTUBS)
include ../Makeconf
diff --git a/devnode/devnode.c b/devnode/devnode.c
index 947d31b..61fc509 100644
--- a/devnode/devnode.c
+++ b/devnode/devnode.c
@@ -89,41 +89,41 @@ devnode_demuxer (mach_msg_header_t *inp,
/* Implementation of notify interface */
kern_return_t
-do_mach_notify_port_deleted (mach_port_t notify,
+do_mach_notify_port_deleted (struct port_info *pi,
mach_port_t name)
{
return EOPNOTSUPP;
}
kern_return_t
-do_mach_notify_msg_accepted (mach_port_t notify,
+do_mach_notify_msg_accepted (struct port_info *pi,
mach_port_t name)
{
return EOPNOTSUPP;
}
kern_return_t
-do_mach_notify_port_destroyed (mach_port_t notify,
+do_mach_notify_port_destroyed (struct port_info *pi,
mach_port_t port)
{
return EOPNOTSUPP;
}
kern_return_t
-do_mach_notify_no_senders (mach_port_t notify,
+do_mach_notify_no_senders (struct port_info *pi,
mach_port_mscount_t mscount)
{
- return ports_do_mach_notify_no_senders (notify, mscount);
+ return ports_do_mach_notify_no_senders (pi, mscount);
}
kern_return_t
-do_mach_notify_send_once (mach_port_t notify)
+do_mach_notify_send_once (struct port_info *pi)
{
return EOPNOTSUPP;
}
kern_return_t
-do_mach_notify_dead_name (mach_port_t notify,
+do_mach_notify_dead_name (struct port_info *pi,
mach_port_t name)
{
return EOPNOTSUPP;
diff --git a/devnode/mig-mutate.h b/devnode/mig-mutate.h
new file mode 100644
index 000..f692236
--- /dev/null
+++ b/devnode/mig-mutate.h
@@ -0,0 +1,25 @@
+/*
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ Written by Justus Winter.
+
+ This file is part of the GNU Hurd.
+
+ The GNU Hurd is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2, or (at
+ your option) any later version.
+
+ The GNU Hurd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with the GNU Hurd. If not, see http://www.gnu.org/licenses/. */
+
+#define NOTIFY_INTRAN \
+ port_info_t begin_using_port_info_port (mach_port_t)
+#define NOTIFY_DESTRUCTOR \
+ end_using_port_info (port_info_t)
+#define NOTIFY_IMPORTS \
+ import libports/mig-decls.h;
diff --git a/eth-filter/Makefile b/eth-filter/Makefile
index 16f5d73..0b2 100644
--- a/eth-filter/Makefile
+++ b/eth-filter/Makefile
@@ -24,6 +24,7 @@ DIST_FILES = ourdevice.defs notify.defs
HURDLIBS = ports trivfs fshelp ihash shouldbeinlibc
target = eth-filter
MIGSTUBS = ourdeviceServer.o notifyServer.o
+MIGSFLAGS = -imacros $(srcdir)/mig-mutate.h
OBJS = $(SRCS:.c=.o) $(MIGSTUBS)
include ../Makeconf
diff --git a/eth-filter/filter.c
Re: Upstreaming patches
On Mon, Apr 7, 2014 at 5:57 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: And what is the solution? I *DONT* have the time to fix it all myself. It's as simple as that. What can I do more about it? I believe Samuel has already squeeze his time to make the current bright hurd, thanks. Samuel, If we don't have time, that's just the truth, and stop blaming on yourself please:) Cong Zhang
Please merge the random translator into the Hurd repository
Dear maintainer :)
please merge the random translator (found in [0]) into the main Hurd
repository.
0: git://git.sv.gnu.org/hurd/incubator.git, branch random
Rationale:
The random translator provides /dev/{,u}random that provide
cryptographically secure random numbers. A lot of software depends on
this. Having /dev/{,u}random thus enables more software to run on the
Hurd. The random translator has been tested in Debian/Hurd for quite
some time now. I consider it essential for any Hurd distribution.
Pros:
Integrating it into the main repository ...
* ... gives it a broader exposure to reviews, cleanups, and static
analysis.
* ... makes large-scale changes to the Hurd base easier. The random
translator depends on the API and most likely even internal
implementational details of the core Hurd libraries.
* ... makes packaging the Hurd easier for Debian/Hurd and any other
potential distributions.
Thanks for considering,
Justus
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
On Mon, Apr 7, 2014 at 5:31 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : The one who do this need have the full plan, I don't see why one would need a full plan. A patch deals with just part of the code, you don't need to know *all* the code to review the patch, ping people about what is wrong with it, clean it, etc. I reserve my opinion here. How about we make a upstream branch and do fast iterator merge and other stuff, we review this branch but not the patches, when it's OK, merge the branch to the main upstream branch or just use it as the main upstream branch? Be it a branch or patches lying in Debian package is just the same. See DDE, it *is* a branch already. But if nobody works on it, well things don't happen magically, it's as simple as that :) I don't think so, Debian hurd was the main hurd downstream, and debian hurd drive the hurd development. So, can I mark the dde as needed for hurd even it is experiment, and, commit it and just add some readme like info is enough? why should we make ourselves so hard to maintain our code when no other people care about that? Separate it can not help the development process, but merge the repo will, and make the build and test process easy will make us newbie friendly :)
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit : Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : The one who do this need have the full plan, I don't see why one would need a full plan. Putting it another way, I don't think anybody has the full plan. Which is fine, all medium-to-big projects are like that. Driver related idea may need a full plan:) Cong Zhang
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
Zhang Cong, le Mon 07 Apr 2014 19:36:02 +0800, a écrit : On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault samuel.thiba...@gnu.org wrote: Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit : Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : The one who do this need have the full plan, I don't see why one would need a full plan. Putting it another way, I don't think anybody has the full plan. Which is fine, all medium-to-big projects are like that. Driver related idea may need a full plan:) Again, no. Drivers can work the way they prefer. The driver infrastructure itself doesn't need a bigplan, it is parts of it which need their own. For instance, the IRQ issue I mentioned has its plan by itself, and it doesn't need to interfere with the physical memory allocation issue. Samuel
Re: Please merge the random translator into the Hurd repository
Hi!
On Mon, 07 Apr 2014 13:05:43 +0200, Justus Winter
4win...@informatik.uni-hamburg.de wrote:
please merge the random translator (found in [0]) into the main Hurd
repository.
0: git://git.sv.gnu.org/hurd/incubator.git, branch random
I have previously (years ago) spoken in favor of keeping individual Hurd
system components as separate as bearable. For example, a) because we
actually can do that in the Hurd system (in contrast to a monolithic
system architecture), and b) because we'll never be able to aggregate all
of the Hurd software in one place anyway (because the software is
shared/used elsewhere (glibc, for example, or even our libpthread, which
used to be shared with the independent L4-Hurd development, later with
Viengoos), or for legal reasons (no copyright assignment), or for
practical reasons (intolerable code quality), for example). I went on to
suggest we might even split up the current Hurd repository into separate
repositories for: RPC definitions, core libraries, translators, tools --
and also remove some of the cruft living in the current core Hurd
repository, without having seen any maintenancen/use for years.
Of course, this makes it harder to do global changes (like, incompatible
changes at the RPC level) -- but because of b) that shouldn't/can't be
done anyway.
Rationale:
The random translator provides /dev/{,u}random that provide
cryptographically secure random numbers. A lot of software depends on
this. Having /dev/{,u}random thus enables more software to run on the
Hurd. The random translator has been tested in Debian/Hurd for quite
some time now. I consider it essential for any Hurd distribution.
That is correct, but my reasoning back then, basically my comment a), has
been that this is not the duty of the core Hurd package, but instead is
the duty of the operating system distribution, which provides installable
packages assembled from various sources, and provides/installs a default
set of packages, which would certainly include the one with the
translator providing /dev/random.
Pros:
Integrating it into the main repository ...
* ... gives it a broader exposure to reviews, cleanups, and static
analysis.
* ... makes large-scale changes to the Hurd base easier. The random
translator depends on the API and most likely even internal
implementational details of the core Hurd libraries.
* ... makes packaging the Hurd easier for Debian/Hurd and any other
potential distributions.
If there is agreement, despite my comment b), that it'd be beneficial to
merge the current external translators into the Hurd core repository's
master branch, if this substantially makes any workflows easier, then I'm
fine with accepting this. There is, I guess, no need to make our lives
harder, for some abstract (?) benefits, just for the elegance of
explicitly modularized system architecture?
Grüße,
Thomas
pgpYIGsvV9IrU.pgp
Description: PGP signature
Re: Please merge the random translator into the Hurd repository
On Mon, Apr 07, 2014 at 01:49:52PM +0200, Thomas Schwinge wrote: If there is agreement, despite my comment b), that it'd be beneficial to merge the current external translators into the Hurd core repository's master branch, if this substantially makes any workflows easier, then I'm fine with accepting this. There is, I guess, no need to make our lives harder, for some abstract (?) benefits, just for the elegance of explicitly modularized system architecture? Grouping translators together along with the Hurd libraries and build system makes the life of developers a lot easier. It reduces the overhead related to build system settings, and it also reduces the likeliness of mistakes. It really is the pragmatic approach, and IMO, it strongly beats the apparent advantages of separate repositories. From experience, on this project or others, I've never actually seen or felt in any way any of these advantages in practice, but I've hit the issues many times... -- Richard Braun
Re: Please merge the random translator into the Hurd repository
Richard Braun, le Mon 07 Apr 2014 13:58:08 +0200, a écrit : On Mon, Apr 07, 2014 at 01:49:52PM +0200, Thomas Schwinge wrote: If there is agreement, despite my comment b), that it'd be beneficial to merge the current external translators into the Hurd core repository's master branch, if this substantially makes any workflows easier, then I'm fine with accepting this. There is, I guess, no need to make our lives harder, for some abstract (?) benefits, just for the elegance of explicitly modularized system architecture? Grouping translators together along with the Hurd libraries and build system makes the life of developers a lot easier. It reduces the overhead related to build system settings, and it also reduces the likeliness of mistakes. It really is the pragmatic approach, and IMO, it strongly beats the apparent advantages of separate repositories. From experience, on this project or others, I've never actually seen or felt in any way any of these advantages in practice, but I've hit the issues many times... Well, Xorg changed his position on this, but perhaps too much indeed :) Samuel
Re: Please merge the random translator into the Hurd repository
On Mon, Apr 7, 2014 at 7:58 PM, Richard Braun rbr...@sceen.net wrote: Grouping translators together along with the Hurd libraries and build system makes the life of developers a lot easier. It reduces the overhead related to build system settings, and it also reduces the likeliness of mistakes. It really is the pragmatic approach +1 Cong Zhang
Add a new exec_exec_file_name RPC
Hi :) this is a rebased patch series created by Emilio Pozuelo Monfort. I've slightly amended the first patch. This patch series makes the fakeroot translator usable, more precisely the execution of interpreted scripts within the fakeroot environment. Both the patch series and my amendment have received considerable testing in the Debian hurd package. Cheers, Justus
[PATCH 1/3] Add a new exec_exec_file_name RPC
From: Emilio Pozuelo Monfort poch...@gmail.com
This is Emilios patch, slightly amended so that the code in hashexec.c
actually uses the provided name. This makes it work in a fakerooted
environment.
* hurd/exec.defs (exec_exec_file_name): New RPC.
(exec_exec): Label as deprecated.
* doc/hurd.texi: Updated.
* exec/exec.c (S_exec_exec_file_name): New function.
(S_exec_exec): Label as deprecated.
(do_exec): Add argument.
* exec/hashexec.c (check_hashbang): Add argument.
Don't guess the file name if file_name_exec is set.
* exec/priv.h (check_hashbang): Add argument.
Signed-off-by: Jeremie Koenig j...@jk.fr.eu.org
Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de
---
doc/hurd.texi | 8 ++---
exec/exec.c | 48 ++---
exec/hashexec.c | 95 +
exec/priv.h | 4 ++-
hurd/exec.defs | 19 ++--
5 files changed, 123 insertions(+), 51 deletions(-)
diff --git a/doc/hurd.texi b/doc/hurd.texi
index 07ddfb4..49a8536 100644
--- a/doc/hurd.texi
+++ b/doc/hurd.texi
@@ -102,7 +102,7 @@ This file documents the GNU Hurd kernel component. This
edition of the
documentation was last updated for version @value{VERSION} of the Hurd.
Copyright @copyright{} 1994, 1996, 1998, 1999, 2000, 2001, 2002, 2003,
-2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+2004, 2005, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
@quotation
Permission is granted to make and distribute verbatim copies of
@@ -2766,14 +2766,14 @@ If the setuid/setgid transformation adds a new uid or
gid to the user's
authentication handle that was not previously present (as opposed to
merely reordering them), then the @code{EXEC_SECURE} and
@code{EXEC_NEWTASK} flags should both be added in the call to
-@code{exec_exec}.
+@code{exec_exec_file_name}.
The server then needs to open a new port onto the executed file which
will not share any file pointers with the port the user passed in,
opened with @code{O_READ}. Finally, all the information (mutated
appropriately for setuid/setgid) should be sent to the execserver with
-@code{exec_exec}. Whatever error code @code{exec_exec} returns should
-returned to the caller of @code{file_exec}.
+@code{exec_exec_file_name}. Whatever error code @code{exec_exec_file_name}
+returns should be returned to the caller of @code{file_exec}.
@node File Locking
@subsection File Locking
diff --git a/exec/exec.c b/exec/exec.c
index 935762e..3d12e09 100644
--- a/exec/exec.c
+++ b/exec/exec.c
@@ -1,6 +1,6 @@
/* GNU Hurd standard exec server.
- Copyright (C) 1992,93,94,95,96,98,99,2000,01,02,04
- Free Software Foundation, Inc.
+ Copyright (C) 1992 ,1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
+ 2002, 2004, 2010 Free Software Foundation, Inc.
Written by Roland McGrath.
Can exec ELF format directly.
@@ -738,6 +738,7 @@ static error_t
do_exec (file_t file,
task_t oldtask,
int flags,
+char *filename,
char *argv, mach_msg_type_number_t argvlen, boolean_t argv_copy,
char *envp, mach_msg_type_number_t envplen, boolean_t envp_copy,
mach_port_t *dtable, mach_msg_type_number_t dtablesize,
@@ -796,7 +797,7 @@ do_exec (file_t file,
{
/* Check for a #! executable file. */
check_hashbang (e,
- file, oldtask, flags,
+ file, oldtask, flags, filename,
argv, argvlen, argv_copy,
envp, envplen, envp_copy,
dtable, dtablesize, dtable_copy,
@@ -1371,6 +1372,7 @@ do_exec (file_t file,
return e.error;
}
+/* Deprecated. */
kern_return_t
S_exec_exec (struct trivfs_protid *protid,
file_t file,
@@ -1387,13 +1389,51 @@ S_exec_exec (struct trivfs_protid *protid,
mach_port_t *deallocnames, mach_msg_type_number_t ndeallocnames,
mach_port_t *destroynames, mach_msg_type_number_t ndestroynames)
{
+ return S_exec_exec_file_name (protid,
+ file,
+ oldtask,
+ flags,
+ ,
+ argv, argvlen, argv_copy,
+ envp, envplen, envp_copy,
+ dtable, dtablesize,
+ dtable_copy,
+ portarray, nports,
+ portarray_copy,
+ intarray, nints,
+ intarray_copy,
+ deallocnames, ndeallocnames,
+ destroynames, ndestroynames);
+}
+
+kern_return_t
+S_exec_exec_file_name (struct trivfs_protid *protid,
+ file_t file,
+ task_t oldtask,
+ int flags,
+ char *filename,
+ char *argv,
[PATCH 3/3] Use the new _hurd_exec_file_name function
From: Emilio Pozuelo Monfort poch...@gmail.com
* configure.in: Check for _hurd_exec_file_name.
* utils/fakeauth.c: Call _hurd_exec_file_name instead of
_hurd_exec if it's available.
* utils/rpctrace.c: Likewise.
* utils/shd.c: Likewise.
Signed-off-by: Jeremie Koenig j...@jk.fr.eu.org
Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de
---
configure.ac | 4 ++--
utils/fakeauth.c | 9 +++--
utils/rpctrace.c | 8 ++--
utils/shd.c | 9 ++---
4 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index ecabfdf..6226e1a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -160,8 +160,8 @@ else
fi
AC_SUBST(VERSIONING)
-# Check if libc contains getgrouplist and/or uselocale.
-AC_CHECK_FUNCS(getgrouplist uselocale)
+# Check if libc contains these functions.
+AC_CHECK_FUNCS(getgrouplist uselocale _hurd_exec_file_name)
# From glibc HEAD, 2007-11-07.
diff --git a/utils/fakeauth.c b/utils/fakeauth.c
index 590a421..851772c 100644
--- a/utils/fakeauth.c
+++ b/utils/fakeauth.c
@@ -1,5 +1,5 @@
/* fakeauth -- proxy auth server to lie to users about what their IDs are
- Copyright (C) 2002 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2010 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
@@ -397,7 +397,7 @@ believe it has restricted them to different identities or
no identity at all.\
/* We cannot use fork because it doesn't do the right thing with our send
rights that point to our own receive rights, i.e. the new auth port.
Since posix_spawn might be implemented with fork (prior to glibc 2.3),
- we cannot use that simple interface either. We use _hurd_exec
+ we cannot use that simple interface either. We use _hurd_exec_file_name
directly to effect what posix_spawn does in the simple case. */
{
task_t newtask;
@@ -422,7 +422,12 @@ believe it has restricted them to different identities or
no identity at all.\
if (err)
error (3, err, proc_child);
+#ifdef HAVE__HURD_EXEC_FILE_NAME
+err = _hurd_exec_file_name (newtask, execfile, argv[argi],
+ argv[argi], environ);
+#else
err = _hurd_exec (newtask, execfile, argv[argi], environ);
+#endif
mach_port_deallocate (mach_task_self (), newtask);
mach_port_deallocate (mach_task_self (), execfile);
if (err)
diff --git a/utils/rpctrace.c b/utils/rpctrace.c
index d7ee203..17acb8d 100644
--- a/utils/rpctrace.c
+++ b/utils/rpctrace.c
@@ -1,7 +1,7 @@
/* Trace RPCs sent to selected ports
- Copyright (C) 1998, 1999, 2001, 2002, 2003, 2005, 2006, 2009, 2011,
- 2013 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999, 2001, 2002, 2003, 2005, 2006, 2009, 2010,
+ 2011, 2013 Free Software Foundation, Inc.
This file is part of the GNU Hurd.
@@ -1734,7 +1734,11 @@ traced_spawn (char **argv, char **envp)
/* Now actually run the command they told us to trace. We do the exec on
the actual task, so the RPCs to map in the program itself do not get
traced. Could have an option to use TASK_WRAPPER here instead. */
+#ifdef HAVE__HURD_EXEC_FILE_NAME
+ err = _hurd_exec_file_name (traced_task, file, *argv, argv, envp);
+#else
err = _hurd_exec (traced_task, file, argv, envp);
+#endif
if (err)
error (2, err, cannot exec `%s', argv[0]);
diff --git a/utils/shd.c b/utils/shd.c
index a1a4b26..855284f 100644
--- a/utils/shd.c
+++ b/utils/shd.c
@@ -1,5 +1,5 @@
/*
- Copyright (C) 1994,95,99,2002 Free Software Foundation
+ Copyright (C) 1994, 1995, 1999, 2002, 2010 Free Software Foundation
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
@@ -159,15 +159,18 @@ run (char **argv, int fd0, int fd1)
movefd (fd1, 1, save1))
return -1;
+#ifdef HAVE__HURD_EXEC_FILE_NAME
+ err = _hurd_exec_file_name (task, file, program, argv, environ);
+#else
err = _hurd_exec (task, file, argv, environ);
-
+#endif
if (restorefd (fd0, 0, save0) ||
restorefd (fd1, 1, save1))
return -1;
if (err)
{
- error (0, err, _hurd_exec);
+ error (0, err, _hurd_exec_file_name);
err = task_terminate (task);
if (err)
error (0, err, task_terminate);
--
1.9.1
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: Again, no. Drivers can work the way they prefer. The driver infrastructure itself doesn't need a bigplan, it is parts of it which need their own. For instance, the IRQ issue I mentioned has its plan by itself, and it doesn't need to interfere with the physical memory allocation issue. That's not sure, unless we have a plenty of driver works, we may need adjust the infrastructure for the need or some new abstract . Although we have driver infrastructure, no enough third part driver provider now. The audio driver and video driver may be part of hurd at first ( just on repo's view), at least some high level abstract, this need a plan. Cong Zhang
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit : On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault samuel.thiba...@gnu.org wrote: Again, no. Drivers can work the way they prefer. The driver infrastructure itself doesn't need a bigplan, it is parts of it which need their own. For instance, the IRQ issue I mentioned has its plan by itself, and it doesn't need to interfere with the physical memory allocation issue. That's not sure, unless we have a plenty of driver works, we may need adjust the infrastructure for the need or some new abstract . Yes, but that new abstract will be independant from other matters concerning drivers. Although we have driver infrastructure, no enough third part driver provider now. The audio driver and video driver may be part of hurd at first ( just on repo's view), at least some high level abstract, this need a plan. Sure. You need a plan for audio, a plan for video. But you don't need a plan for both audio video at the same time, except some general Hurdish principles, but that's not big. Samuel
Re: GNU accepted as a mentoring organization in GSOC 2014
On Fri, Mar 21, 2014 at 12:50 AM, Thomas Schwinge tho...@codesourcery.comwrote: Hi! Welcome back! ;-) On Thu, 20 Mar 2014 22:40:13 +0800, Yue Lu hacklu.newb...@gmail.com wrote: On Tue, Feb 25, 2014 at 4:53 PM, Thomas Schwinge tho...@codesourcery.comwrote: GDB: »catch syscall«; pretty-printing of mach_msg. https://www.gnu.org/software/hurd/open_issues/gdb_catch_syscall.html , https://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html. That translates to us to »break mach_msg« with suitable RPC name matching. Pretty printing of mach_msg arguments à la rpctrace. Might these days be implemented as a Python pretty-printer in GDB. I have some interesting with this ideal. Also, your gdbserver work still needs to be integrated upstream, so that is another thing to work on. I am very interesting in that will the gdb server be a workaround for hurd gdb's warning: Can't wait for pid ???: No child processes problem? Can anyone has workable gdb server to do a test? Can't continue really make me crazy and not so convenience. Thanks, Cong Zhang
Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
On Mon, Apr 7, 2014 at 8:55 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit : On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault samuel.thiba...@gnu.org wrote: Again, no. Drivers can work the way they prefer. The driver infrastructure itself doesn't need a bigplan, it is parts of it which need their own. For instance, the IRQ issue I mentioned has its plan by itself, and it doesn't need to interfere with the physical memory allocation issue. That's not sure, unless we have a plenty of driver works, we may need adjust the infrastructure for the need or some new abstract . Yes, but that new abstract will be independant from other matters concerning drivers. Although we have driver infrastructure, no enough third part driver provider now. The audio driver and video driver may be part of hurd at first ( just on repo's view), at least some high level abstract, this need a plan. Sure. You need a plan for audio, a plan for video. But you don't need a plan for both audio video at the same time, except some general Hurdish principles, but that's not big. OK, not big is a good message:) Thanks, Cong Zhang
GDB: warning: Can't wait for pid ???: No child processes (was: GNU accepted as a mentoring organization in GSOC 2014)
Hi! On Tue, 8 Apr 2014 00:20:57 +0800, Zhang Cong congzh...@mathphoenix.com wrote: I am very interesting in that will the gdb server be a workaround for hurd gdb's warning: Can't wait for pid ???: No child processes problem? Can anyone has workable gdb server to do a test? Can't continue really make me crazy and not so convenience. It'd be more useful if you described what you're trying to do, and how that's failing with native GDB debugging. :-) That said, last summer's gdbserver work by Yue Lu is available at https://github.com/hacklu/gdbserver/tree/gdbserver. Grüße, Thomas pgpUSPXDDYWpR.pgp Description: PGP signature
Re: Glibc building procedure error report.
I am having some problems with building the libpthread addon. I get the error ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER -- but I can't seem to find this ^ ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:46:33: note: in expansion of macro '_HURD_THREADVAR_THREAD' __hurd_threadvar_location (_HURD_THREADVAR_THREAD);\ ^ ./pthread/../sysdeps/generic/pt-barrier-wait.c:52:32: note: in expansion of macro '_pthread_self' struct __pthread *self = _pthread_self (); I searched the source files for the macros '_HURD_THREADVAR_DYNAMIC_USER' and '_HURD_THREADVAR_THREAD' and I can't seem to find them so where are they used? I noticed '_HURD_THREADVAR_DYNAMIC_USER' used to be in /hurd/hurd/threadvar.h but now it's removed. Any ideas?
Re: Glibc building procedure error report.
Manolis Ragkousis, le Mon 07 Apr 2014 19:49:02 +, a écrit : I am having some problems with building the libpthread addon. I get the error ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) Which version of libpthread is this? I don't have this in my copy of the tree. We got rid of these a long time ago. Samuel
Re: Glibc building procedure error report.
2014-04-07 21:05 GMT+00:00 Samuel Thibault samuel.thiba...@gnu.org: Which version of libpthread is this? I don't have this in my copy of the tree. We got rid of these a long time ago. I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44
Re: Glibc building procedure error report.
Manolis Ragkousis, le Mon 07 Apr 2014 21:11:40 +, a écrit : 2014-04-07 21:05 GMT+00:00 Samuel Thibault samuel.thiba...@gnu.org: Which version of libpthread is this? I don't have this in my copy of the tree. We got rid of these a long time ago. I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44 Well, there's something fishy in there: in my clone ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:46 is __mach_port_deallocate (__mach_task_self (), ktid);\ and there is no occurrence of threadvar in the tree. Samuel
Re: Add a new exec_exec_file_name RPC
Well, I'm not the one to be convinced: it's only Roland which can ack the glibc part, and thus the whole idea of the RPC addition. One just needs to explain him why we really need it. Samuel
