Re: [PATCH] Make start_code and end_code available in /proc/*/stat
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 + left alone. */ + else + proc_get_code (p, start_code, end_code); 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. What do you think? To be honest, I spent most of the time on that part, thinking that the chances of getting this merged without discussion would improve if I just implement this instead of providing wrong values to appease killall5. Also, providing the correct values aligns our procfs more closely with the Linux one, and that is one of the points of our procfs, isn't it? Justus
Re: [PATCH 03/17] Add proc_set_init_task, make runsystem pid 1
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 reaping code from /hurd/init. Justus
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
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 essential process, crashing it makes /hurd/init crash the whole system. 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. Funny, I actually thought that the unzipping code is the uninteresting part, while the BFD code could hope to be revived. From what I've seen it is much nicer to use than the ELF parser we currently use. 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. Out of curiosity, why do you consider this feature interesting? Justus
Re: [PATCH 1/3] Define and use symbolic names for important processes
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. Justus
Re: [PATCH] Make start_code and end_code available in /proc/*/stat
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. What do you think? To be honest, I spent most of the time on that part, thinking that the chances of getting this merged without discussion would improve if I just implement this instead of providing wrong values to appease killall5. Also, providing the correct values aligns our procfs more closely with the Linux one, and that is one of the points of our procfs, isn't it? What's the problem with adding support for valid values ? -- Richard Braun
Re: [PATCH 1/3] Define and use symbolic names for important 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 compileable out-of-tree) nor the glibc can use the symbolic names. I'd be very reluctant to expose such kind of information statically. Does procfs really need this information? As for glibc, I know it needs it at least for reboot(), but I'd rather not give the information through a static macro. Samuel
Re: [PATCH] Make start_code and end_code available in /proc/*/stat
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 0x0800 / 0x0900 values for non-essential processes. What do you think? To be honest, I spent most of the time on that part, thinking that the chances of getting this merged without discussion would improve if I just implement this instead of providing wrong values to appease killall5. Also, providing the correct values aligns our procfs more closely with the Linux one, and that is one of the points of our procfs, isn't it? What's the problem with adding support for valid values ? I just mean it's more code not necessarily interesting for other use cases. I'm not against it, I'm just wondering how much useful it is. Samuel
Re: Warnings about error_t in glibc on GNU/Hurd
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 much. Perhaps something like: /* The value zero always means success and it is perfectly fine for code to use 0 explicitly (or implicitly, e.g. via Boolean coercion). Having an enum entry for zero both makes the debugger print the name for error_t-typed zero values, and prevents the compiler from issuing warnings about 'case 0:' in a switch on an error_t-typed value. */ Thanks; pushed as commit 883359805325a82f4f291ff85624f141f6c93636 using your above words. Grüße, Thomas pgpryw_8XOONT.pgp Description: PGP signature
Re: [PATCH,HURD] Recognize GNU/Hurd-specific binaries
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. ports/ChangeLog.arm * sysdeps/unix/sysv/linux/arm/ldsodefs.h (VALID_ELF_OSABI) (MORE_ELF_HEADER_DATA): Use ELFOSABI_GNU instead of ELFOSABI_LINUX. ports/ChangeLog.mips * sysdeps/unix/sysv/linux/mips/ldsodefs.h (VALID_ELF_ABIVERSION): Use ELFOSABI_GNU instead of ELFOSABI_LINUX. This is fine. Pushed as commit c54290cf086940e3859b236d0fb880bacab2288b. I suggest we instead implement this in sysdeps/gnu/ldsodefs.h, as this is a common GNU thing. That is a good thing to do. Tested on x86 and x86_64 GNU/Linux, and x86 GNU/Hurd; glibc testsuite as well as manually as follows: Verify on x86_64-linux-gnu that the change has no effect whatsoever on the compiled code. Had done this back then. * sysdeps/unix/sysv/linux/ldsodefs.h (VALID_ELF_HEADER) (VALID_ELF_OSABI, VALID_ELF_ABIVERSION, MORE_ELF_HEADER_DATA): Move macros to... * sysdeps/gnu/ldsodefs.h: ... this new file. With that verified, this is fine. Pushed as commit d821f07c9e9575b47df87cc38f26c31e09b3ce0d. Grüße, Thomas pgpz8pMcrEa9r.pgp Description: PGP signature
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
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 whole exec code a lot more complex to understand. Since even the TODO talks about ditching it away, and reviving and maintaining it would be a burden, it's better to just not keep it, and have readable exec instead. Out of curiosity, why do you consider this feature interesting? 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 the feature doesn't seem so appealing, the maintenance cost is light. Samuel
Re: [PATCH 1/3] Define and use symbolic names for important processes
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. This means that neither procfs (being maintained and compileable out-of-tree) nor the glibc can use the symbolic names. I'd be very reluctant to expose such kind of information statically. Agreed, but Does procfs really need this information? Kinda. main.c (main) reads: opt_kernel_pid = 2; Ugh. As for glibc, I know it needs it at least for reboot(), but I'd rather not give the information through a static macro. This particular case could indeed be handled more elegantly by looking up the port using /servers/startup as discussed somewhere (irc?). Justus
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
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 on /hurd/exec. Yes, the BFD code was making the whole exec code a lot more complex to understand. Since even the TODO talks about ditching it away, and reviving and maintaining it would be a burden, it's better to just not keep it, and have readable exec instead. Agreed, the BFD stuff was much more intrusive. Out of curiosity, why do you consider this feature interesting? 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 the feature doesn't seem so appealing, the maintenance cost is light. But couldn't the same be archived by installing an unzipping storeio translator on the zipped executable? It is more explicit, but I'd argue that this is a good thing in this case and shows the flexibility of the Hurd as a whole. Justus
Re: [PATCH 1/3] Define and use symbolic names for important processes
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 rather not give the information through a static macro. This particular case could indeed be handled more elegantly by looking up the port using /servers/startup as discussed somewhere (irc?). Indeed. Samuel
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
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 the feature doesn't seem so appealing, the maintenance cost is light. 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 in this case and shows the flexibility of the Hurd as a whole. That better separates matters indeed. Not duplicating the deflate code is a sign of better factorization :) What do people think about it? That can mean, with nsmux, to exec, say, foo.gz,,gunzip for instance, instead of guessing. Samuel
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
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 gzip/bzip2 support only has a couple of hooks, so even if the feature doesn't seem so appealing, the maintenance cost is light. 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 in this case and shows the flexibility of the Hurd as a whole. That better separates matters indeed. Not duplicating the deflate code is a sign of better factorization :) What do people think about it? That can mean, with nsmux, to exec, say, foo.gz,,gunzip for instance, instead of guessing. Umm, I just tested this, and it doesn't work :/ I guess b/c storeio claims that it is a character device: % ls -l /tmp/hello.unzipped crwxr-xr-x 1 teythoon teythoon 0, 0 Aug 29 13:01 /tmp/hello.unzipped % /tmp/hello.unzipped zsh: permission denied: /tmp/hello.unzipped % /lib/ld.so.1 /tmp/hello.unzipped /tmp/hello.unzipped: Must be started as a translator Justus
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
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 in this case and shows the flexibility of the Hurd as a whole. That better separates matters indeed. Not duplicating the deflate code is a sign of better factorization :) What do people think about it? That can mean, with nsmux, to exec, say, foo.gz,,gunzip for instance, instead of guessing. A better example would be providing an exec server for old a.out static binaries for example. But for compression, what Justus describes looks a lot more hurdish to me. -- Richard Braun
Re: mtab translator (v4)
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
Re: mtab translator (v4)
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 have applied these for now. Why for now? Anything wrong with them? No, I mean that for now I haven't applied the rest of the patch series. Samuel
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
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 translator to do transparent decompression for files in general. That's what's really interesting. The only reason you might need the support directly in the exec server is to use compressed binaries for the bootstrap tasks, and I doubt that's all that interesting these days (it was when we wanted to fit a bootable system on a floppy disk 20 years ago).
Re: [PATCH 4/5] exec: Remove #ifdef 0-out code for user specified exec servers.
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. Maybe Thomas would recall, but probably not.
Re: [PATCH 5/5] exec: remove the BFD code
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 is for the linker. It's not even sufficient for ELF.
Re: [PATCH 3/5] exec: Remove #ifdef 0-out code doing nothing.
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 sysdeps/mach/hurd/dl-sysdep.c that works around an old bug in vm_map when trying to use the mask. If you've fixed the microkernel bug, then you can both rip out the hack, and enable the mask in the exec server.
Re: [PATCH] umount: add a umount utility
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 an error. It would be nice to remove this build dependency if it isn't actually required. Thanks. David
Re: [PATCH] umount: add a umount utility
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
Re: [PATCH] umount: add a umount utility
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 guess. Indeed, good catch! Justus
