Quoting Samuel Thibault (2013-08-29 00:24:59)
Justus Winter, le Mon 05 Aug 2013 12:11:30 +0200, a écrit :
+ if (essential)
+ start_code = end_code = 0; /* To make killall5.c consider it a
+ kernel process that is to be
+
Quoting Samuel Thibault (2013-08-29 01:48:10)
I think we should keep this in the Debian package, the upstream GNU
system will a priori still use /hurd/init as reaper.
Well, it is not my place to question this and maintaining the patches
is your burden, but I was hoping to remove the process
Quoting Samuel Thibault (2013-08-28 23:56:10)
Hello,
Justus Winter, le Thu 15 Aug 2013 18:41:50 +0200, a écrit :
Remove support for transparently unbzip2ing executables from the exec
server. The code in question makes the exec server unnecessarily
complex and since the exec server is an
Quoting Samuel Thibault (2013-08-28 23:30:27)
Applied this one, thanks.
This one as in the private header file?
I've come across an issue with the header being private. This means
that neither procfs (being maintained and compileable out-of-tree) nor
the glibc can use the symbolic names.
On Thu, Aug 29, 2013 at 12:05:30PM +0200, Justus Winter wrote:
Quoting Samuel Thibault (2013-08-29 00:24:59)
Mmm, I'm not sure whether we really want to introduce
proc_set_code/proc_get_code just for killall5. We could just put
0x0800 / 0x0900 values for non-essential processes.
Justus Winter, le Thu 29 Aug 2013 12:22:30 +0200, a écrit :
Quoting Samuel Thibault (2013-08-28 23:30:27)
Applied this one, thanks.
This one as in the private header file?
Yes.
I've come across an issue with the header being private. This means
that neither procfs (being maintained and
Richard Braun, le Thu 29 Aug 2013 12:23:54 +0200, a écrit :
On Thu, Aug 29, 2013 at 12:05:30PM +0200, Justus Winter wrote:
Quoting Samuel Thibault (2013-08-29 00:24:59)
Mmm, I'm not sure whether we really want to introduce
proc_set_code/proc_get_code just for killall5. We could just put
Hi!
On Wed, 29 May 2013 15:53:24 -0700 (PDT), Roland McGrath rol...@hack.frob.com
wrote:
+ /* Avoid warning: case value '0' not in enumerated type 'error_t'. */
+ ESUCCESS = 0,
I don't think this is the right comment. If anybody reads this comment at
all, that doesn't tell them
Hi!
On Wed, 29 May 2013 15:01:40 -0700 (PDT), Roland McGrath rol...@hack.frob.com
wrote:
First, my usual cleanup patch:
* sysdeps/unix/sysv/linux/ldsodefs.h (VALID_ELF_OSABI)
(VALID_ELF_ABIVERSION, MORE_ELF_HEADER_DATA): Use ELFOSABI_GNU
instead of ELFOSABI_LINUX.
Justus Winter, le Thu 29 Aug 2013 12:16:11 +0200, a écrit :
The patches were also ment to address the complexity^Wsheer size of
the code. That is why I wanted to remove them, #ifdef'ing it out has a
cost, not a runtime one but for anyone hacking on /hurd/exec.
Yes, the BFD code was making the
Quoting Samuel Thibault (2013-08-29 12:28:34)
Justus Winter, le Thu 29 Aug 2013 12:22:30 +0200, a écrit :
Quoting Samuel Thibault (2013-08-28 23:30:27)
Applied this one, thanks.
This one as in the private header file?
Yes.
I've come across an issue with the header being private.
Quoting Samuel Thibault (2013-08-29 12:32:50)
Justus Winter, le Thu 29 Aug 2013 12:16:11 +0200, a écrit :
The patches were also ment to address the complexity^Wsheer size of
the code. That is why I wanted to remove them, #ifdef'ing it out has a
cost, not a runtime one but for anyone hacking
Justus Winter, le Thu 29 Aug 2013 12:35:32 +0200, a écrit :
Does procfs really need this information?
Kinda. main.c (main) reads:
opt_kernel_pid = 2;
Ugh.
Ugh.
That could probably be provided by the startup server?
As for glibc, I know it needs
it at least for reboot(), but I'd
Justus Winter, le Thu 29 Aug 2013 12:41:47 +0200, a écrit :
At least to show flexibility of the exec server. The difference between
the BFD code and the gzip/bzip2 code is that the latter makes the whole
exec code complex, while the gzip/bzip2 support only has a couple of
hooks, so even if
Quoting Samuel Thibault (2013-08-29 12:52:39)
Justus Winter, le Thu 29 Aug 2013 12:41:47 +0200, a écrit :
At least to show flexibility of the exec server. The difference between
the BFD code and the gzip/bzip2 code is that the latter makes the whole
exec code complex, while the
On Thu, Aug 29, 2013 at 12:52:39PM +0200, Samuel Thibault wrote:
Justus Winter, le Thu 29 Aug 2013 12:41:47 +0200, a écrit :
But couldn't the same be achieved by installing an unzipping storeio
translator on the zipped executable? It is more explicit, but I'd
argue that this is a good thing
Quoting Samuel Thibault (2013-08-29 01:29:50)
Justus Winter, le Tue 30 Jul 2013 11:59:08 +0200, a écrit :
[PATCH 01/16] libnetfs: implement file_get_translator_cntl
[PATCH 02/16] libnetfs: handle dead-name notifications
I have applied these for now.
Why for now? Anything wrong with them?
Justus Winter, le Thu 29 Aug 2013 14:41:22 +0200, a écrit :
Quoting Samuel Thibault (2013-08-29 01:29:50)
Justus Winter, le Tue 30 Jul 2013 11:59:08 +0200, a écrit :
[PATCH 01/16] libnetfs: implement file_get_translator_cntl
[PATCH 02/16] libnetfs: handle dead-name notifications
I
Right. The feature is however still somehow interesting, so I prefered
to just disable the support by default, so users can easily build their
own exec server and set it up for themselves if they wish.
Doing this in the exec server was always just a cheap hack because we
didn't have a
There was some reason for the EXECSERVERS environment variable and I think
it might not have been just because we didn't yet have the various
translators (unionfs, etc.) that would make it straightforward to populate
a private root directory for such purposes. But I really can't recall any
more.
Indeed it was a nice idea to be able to execute any format for free,
and it worked great for the most trivial format known to man (a.out).
But the fantasy that BFD actually adequately encapsulates all the
object format details so you don't need to know them is no more true
for the loader than it
Mmm, the comment still looks valid to me. I don't know what else would
make sure the dynamic linker doesn't put anything where libc expects to
be putting its heap. We need to make sure something does that before
dropping such a scary warning.
It's the fmh hack in
Hi,
On Thu, Aug 15, 2013 at 2:23 AM, Justus Winter
4win...@informatik.uni-hamburg.de wrote:
+#include blkid/blkid.h
Does umount.c use anything in blkid.h? It seems to build with that
line removed.
I didn't have libblkid's development files installed when I first
tried building umount, causing
David Michael, le Thu 29 Aug 2013 15:04:34 -0400, a écrit :
On Thu, Aug 15, 2013 at 2:23 AM, Justus Winter
4win...@informatik.uni-hamburg.de wrote:
+#include blkid/blkid.h
Does umount.c use anything in blkid.h?
No, this is a leftover I guess.
Thanks,
Samuel
Quoting Samuel Thibault (2013-08-29 21:10:17)
David Michael, le Thu 29 Aug 2013 15:04:34 -0400, a écrit :
On Thu, Aug 15, 2013 at 2:23 AM, Justus Winter
4win...@informatik.uni-hamburg.de wrote:
+#include blkid/blkid.h
Does umount.c use anything in blkid.h?
No, this is a leftover I
25 matches
Mail list logo
