Re: Porting skalibs to GNU Hurd
On Fri, Oct 18, 2019 at 4:08 PM Laurent Bercot wrote: > > > > >So, whoever calls s6_supervise_lock_mode() should correctly die, as > >there is an actual error (that should be reported to the Hurd > >developers); libs6, libskarnet and the libc are just the messengers. > >Commenting out the errno check just sweeps the error under the carpet. > > I assumed the OS was fine, since s6 worked correctly when the check > wasn't performed, and that EIEIO was reported as a catch-all way of > saying "you are trying to do something that cannot happen, i.e. we > haven't planned for this case at all" - which would just be an > oversight in the Hurd fifo code. > > Obviously, if there was a *real* problem during the operation and > EIEIO was reported as a panic, the situation is different and the > check should not be removed. > > And that is why everyone - including kernels - should always use > different error codes for "can't happen" and "unknown run-time issue". > :) > FWIW, it has been fixed in Hurd upstream. http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=9b6afcec2f6cfb2f0e0f01962f8d8fe6bd9f6762 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942558#32 -- Shengjing Zhu
Re: Porting skalibs to GNU Hurd
So, whoever calls s6_supervise_lock_mode() should correctly die, as there is an actual error (that should be reported to the Hurd developers); libs6, libskarnet and the libc are just the messengers. Commenting out the errno check just sweeps the error under the carpet. I assumed the OS was fine, since s6 worked correctly when the check wasn't performed, and that EIEIO was reported as a catch-all way of saying "you are trying to do something that cannot happen, i.e. we haven't planned for this case at all" - which would just be an oversight in the Hurd fifo code. Obviously, if there was a *real* problem during the operation and EIEIO was reported as a panic, the situation is different and the check should not be removed. And that is why everyone - including kernels - should always use different error codes for "can't happen" and "unknown run-time issue". :) -- Laurent
Re: Porting skalibs to GNU Hurd
> Am 18.10.2019 um 09:30 schrieb Jens Rehsack : > > > >> Am 17.10.2019 um 22:12 schrieb Laurent Bercot : >> >>> A reasonable detection in configure stage is definitively to prefer. >> >> Not necessarily. It would work, obviously, but would bloat the build. >> Compile-time generated headers are kinda painful to manage, and I'd like >> to keep their number in check. Also, using configure detection would make >> nonposix.h depend on sysdeps.h, and that's a dependency I'd rather avoid. > > Understood. My experience is vice versa, but therefore different > people are good for. > >>> If stack allocation is a must, maybe it can be evaluated whether >>> alloca can be an alternative. >> >> It cannot. alloca is not POSIX, not portable, and not safe. >> And one of the main advantages of stack allocation is that it keeps the >> code *simple*, compact, and easy to read, as opposed to having malloc() >> calls everywhere; using alloca(), which is also a function call, >> forfeits that advantage. > > It's not - and it would be insane if it would ;) > To reasonable allocate on stack, it has to know about it - so it should > be a compiler builtin: > >> DESCRIPTION >> The alloca() macro allocates size bytes of space in the stack frame of >> the caller. This temporary space is automatically freed on return. > > It might not be POSIX, but it might be available where PATH_MAX isn't. Ah - and wrt. unsafe - yes, especially in C99 variable length array context, which makes C99 preferable over alloca. But it has the same init - dynamically figure out PATH_MAX and initialize the array with it. >> I'll do heap allocation where necessary and where I'm certain that >> stralloc has already been pulled. For the other places, Hurd+skalibs users >> will simply have to avoid ricing their paths. > > As last way out ... > In practice I never encountered FQPN longer than 160 characters. Cheers -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: Porting skalibs to GNU Hurd
> Am 17.10.2019 um 22:12 schrieb Laurent Bercot : > >> A reasonable detection in configure stage is definitively to prefer. > > Not necessarily. It would work, obviously, but would bloat the build. > Compile-time generated headers are kinda painful to manage, and I'd like > to keep their number in check. Also, using configure detection would make > nonposix.h depend on sysdeps.h, and that's a dependency I'd rather avoid. Understood. My experience is vice versa, but therefore different people are good for. >> If stack allocation is a must, maybe it can be evaluated whether >> alloca can be an alternative. > > It cannot. alloca is not POSIX, not portable, and not safe. > And one of the main advantages of stack allocation is that it keeps the > code *simple*, compact, and easy to read, as opposed to having malloc() > calls everywhere; using alloca(), which is also a function call, > forfeits that advantage. It's not - and it would be insane if it would ;) To reasonable allocate on stack, it has to know about it - so it should be a compiler builtin: > DESCRIPTION > The alloca() macro allocates size bytes of space in the stack frame of > the caller. This temporary space is automatically freed on return. It might not be POSIX, but it might be available where PATH_MAX isn't. > I'll do heap allocation where necessary and where I'm certain that > stralloc has already been pulled. For the other places, Hurd+skalibs users > will simply have to avoid ricing their paths. As last way out ... In practice I never encountered FQPN longer than 160 characters. Cheers -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: Porting skalibs to GNU Hurd
El jue., 17 oct. 2019 a las 16:51, Laurent Bercot escribió:
>
> Hurd should return -1 ENXIO,
> unless there is a real problem with the underlying file system - and the
> test your patch comments exists to catch such problems.
…or an error in the underlying operating system. POSIX open() seems
to be implemented directly by the Hurd:
*
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/open.c;h=e093b67c1e3aa99bc3caf485feaf8f226dc0;hb=56c86f5dd516284558e106d04b92875d5b623b7a
.
And the call seems to be failing with that special Hurd errno code,
EIEIO, which... is not a good thing :P
* http://www.gnu.org/software/hurd/faq/eieio.html
"This error code is used for a variety of "hopeless" error conditions.
Most probably you will encounter it when a translator crashes while
you were trying to use a file that it serves."
*
https://sourceware.org/git/?p=glibc.git;a=blob;f=manual/errno.texi;h=8cb4ce8b489dbbc6b3decef023cb3cafa471a32b;hb=56c86f5dd516284558e106d04b92875d5b623b7a
"@errno{EIEIO, 104, Computer bought the farm}
Go home and have a glass of warm, dairy-fresh milk.
[...]
@c Translators, please do not translate this litteraly, translate it into
@c an idiomatic funny way of saying that the computer died."
So, whoever calls s6_supervise_lock_mode() should correctly die, as
there is an actual error (that should be reported to the Hurd
developers); libs6, libskarnet and the libc are just the messengers.
Commenting out the errno check just sweeps the error under the carpet.
G.
Re: Porting skalibs to GNU Hurd
El jue., 17 oct. 2019 a las 17:02, Laurent Bercot escribió: > > >__gnu_hurd__ > > That's perfect. I replaced __GLIBC__ with this. I think __GNU__ is still preferred over __gnu_hurd__, judging by the "Preprocessor Define" and "GNU specific #define" sections of the porting guidelines linked earlier in the thread: * http://www.gnu.org/software/hurd/hurd/porting/guidelines.html Although the intention appears to be that __GNU__ be defined if and only if __gnu_hurd__ is. * https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/gnu.h;h=1cc744b13be567ec1e7177acec59ccd6142960dd;hb=4ac50a4913ed81cc83a8baf865e49a2c62a5fe5d G.
Re: Porting skalibs to GNU Hurd
A reasonable detection in configure stage is definitively to prefer. Not necessarily. It would work, obviously, but would bloat the build. Compile-time generated headers are kinda painful to manage, and I'd like to keep their number in check. Also, using configure detection would make nonposix.h depend on sysdeps.h, and that's a dependency I'd rather avoid. If stack allocation is a must, maybe it can be evaluated whether alloca can be an alternative. It cannot. alloca is not POSIX, not portable, and not safe. And one of the main advantages of stack allocation is that it keeps the code *simple*, compact, and easy to read, as opposed to having malloc() calls everywhere; using alloca(), which is also a function call, forfeits that advantage. I'll do heap allocation where necessary and where I'm certain that stralloc has already been pulled. For the other places, Hurd+skalibs users will simply have to avoid ricing their paths. -- Laurent
Re: Porting skalibs to GNU Hurd
__gnu_hurd__ That's perfect. I replaced __GLIBC__ with this. So skalibs/nonposix.h will define _GNU_SOURCE on Linux and Hurd, i.e. the systems whose function visibility benefits the most from it. Testing kernel ftms is generally ugly, but it's the right thing for nonposix.h whose goal is precisely determining which libc ftms to define in order to maximize visibility of idiomatic system functions, before including libc headers. Thanks, Guillermo and Shengjing. -- Laurent
Re: Porting skalibs to GNU Hurd
The errno I got on Hurd is `EIEIO 1073741928 Computer bought the farm`... Seems a Hurd specific errno... That is really non-conformant, and deserves to be reported to the Hurd team. What is happening is that "control" is a named pipe, and the attempted operation is open(control, O_WRONLY | O_NONBLOCK). If the service isn't running (which is the normal case here because it's a check performed at start, to avoid duplicating a service that is already running), there is no reader on the "control" fifo. And POSIX is very clear on what must happen in that case: https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html says: [ENXIO] O_NONBLOCK is set, the named file is a FIFO, O_WRONLY is set, and no process has the file open for reading. which is *exactly* what's happening here. Hurd should return -1 ENXIO, unless there is a real problem with the underlying file system - and the test your patch comments exists to catch such problems. I think your patch is the correct workaround (although you could specifically catch ENXIO *and* EIEIO instead, and still die on other error codes), but I'm not upstreaming it because the problem isn't in s6. I would suggest keeping the patch in your tree until Hurd is fixed. -- Laurent
Re: Porting skalibs to GNU Hurd
On Thu, Oct 17, 2019 at 7:14 AM Guillermo wrote: > > If compiler predefined macros like __linux__ or __NetBSD__ are OK for > , how about #if defined(__linux__) || > defined(__GNU__)? GCC predefines both __GNU__ and __gnu_hurd__ (I > think, can be checked with 'cpp -dM - the Hurd, and I suppose no other compiler targets that OS... > look at the result of `cpp -dM -
Re: Porting skalibs to GNU Hurd
On Thu, Oct 17, 2019 at 1:10 AM Laurent Bercot wrote: > > What problems did you get with s6? It should be able to run without > trouble. To me that's a more important issue than the ones you listed > below. :) > with the following patch, s6 works...(tested some functions like s6-svscan). diff --git a/src/libs6/s6_supervise_lock_mode.c b/src/libs6/s6_supervise_lock_mode.c index 039760c..8c0843b 100644 --- a/src/libs6/s6_supervise_lock_mode.c +++ b/src/libs6/s6_supervise_lock_mode.c @@ -36,8 +36,8 @@ int s6_supervise_lock_mode (char const *subdir, unsigned int subdirmode, unsigne strerr_diefu2sys(111, "lock ", lock) ; fdctlw = open_write(control) ; if (fdctlw >= 0) strerr_dief1x(100, "directory already locked") ; - if (errno != ENXIO) -strerr_diefu2sys(111, "open_write ", control) ; + //if (errno != ENXIO) + // strerr_diefu2sys(111, "open_write ", control) ; fdctl = open_read(control) ; if (fdctl < 0) strerr_diefu2sys(111, "open_read ", control) ; The errno I got on Hurd is `EIEIO 1073741928 Computer bought the farm`... Seems a Hurd specific errno... -- Shengjing Zhu
Re: Porting skalibs to GNU Hurd
El jue., 17 oct. 2019 a las 4:25, Laurent Bercot escribió: > > Do you mean __GNUC__ instead of __GNU__ ? No, I mean __GNU__ without the "C. __GNUC__ is a different predefined macro. G.
Re: Porting skalibs to GNU Hurd
> Am 17.10.2019 um 01:07 schrieb Guillermo :
>
> El mié., 16 oct. 2019 a las 14:02, Laurent Bercot escribió:
>>
>>> 1. In src/include/skalibs/nonposix.h,
>>>
>>> #if defined(__linux__) || defined(__GLIBC__)
>>> The if condition seems not working. Of course it's not __linux__, but I am
>>> using glibc.
>>
>> Ah, yes, __GLIBC__ is only defined in features.h, you're right.
>
> If compiler predefined macros like __linux__ or __NetBSD__ are OK for
> , how about #if defined(__linux__) ||
> defined(__GNU__)? GCC predefines both __GNU__ and __gnu_hurd__ (I
> think, can be checked with 'cpp -dM - the Hurd, and I suppose no other compiler targets that OS...
A reasonable detection in configure stage is definitively to prefer.
>>> 2. No PATH_MAX macro
>>>
>> What I can promise is to fix every issue that you might
>> get with -DPATH_MAX=4096. And remove the dependencies on PATH_MAX that
>> can be removed painlessly. How does that sound?
>
> Do you mean doing something like:
>
> #ifndef PATH_MAX
> #define PATH_MAX 4096
> #endif
>
> or removing references to PATH_MAX altogether?
If stack allocation is a must, maybe it can be evaluated whether
alloca can be an alternative. When the stack size is assumed to
be large enough, a global variable containing the once computed
size and functions can do:
extern const size_t computed_path_max;
int
foo(...)
{
#ifdef PATH_MAX
char mypath[PATH_MAX];
#else
char *mypath = alloca(computed_path_max);
#endif
...
}
Yes, not 100% satisfying - but maybe a saner way out than
-DPATH_MAX=4096.
Cheers
--
Jens Rehsack - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP
Re: Porting skalibs to GNU Hurd
If compiler predefined macros like __linux__ or __NetBSD__ are OK for , how about #if defined(__linux__) || defined(__GNU__)? GCC predefines both __GNU__ and __gnu_hurd__ (I think, can be checked with 'cpp -dM - Do you mean __GNUC__ instead of __GNU__ ? Testing defined(__GNUC__) would yield true whenever the compiler is gcc, so _GNU_SOURCE would be defined even on BSDs when people use gcc. Not optimal, and would make behaviour different depending on the compiler. I'd rather #define _GNU_SOURCE unconditionally. Do you mean doing something like: #ifndef PATH_MAX #define PATH_MAX 4096 #endif or removing references to PATH_MAX altogether? The latter wherever possible. It's easy enough to compile with -DPATH_MAX=4096, and I'd rather keep it like this than pretend to work without PATH_MAX but fail with very long path names. -- Laurent
Re: Porting skalibs to GNU Hurd
El mié., 16 oct. 2019 a las 14:02, Laurent Bercot escribió: > > >1. In src/include/skalibs/nonposix.h, > > > >#if defined(__linux__) || defined(__GLIBC__) > >The if condition seems not working. Of course it's not __linux__, but I am > >using glibc. > > Ah, yes, __GLIBC__ is only defined in features.h, you're right. If compiler predefined macros like __linux__ or __NetBSD__ are OK for , how about #if defined(__linux__) || defined(__GNU__)? GCC predefines both __GNU__ and __gnu_hurd__ (I think, can be checked with 'cpp -dM - >2. No PATH_MAX macro > > > What I can promise is to fix every issue that you might > get with -DPATH_MAX=4096. And remove the dependencies on PATH_MAX that > can be removed painlessly. How does that sound? Do you mean doing something like: #ifndef PATH_MAX #define PATH_MAX 4096 #endif or removing references to PATH_MAX altogether? G.
Re: Porting skalibs to GNU Hurd
Hi Shengjing, With using `CPPFLAGS += -D_GNU_SOURCE -DPATH_MAX=4096`, skalibs builds on Hurd, execline works fine. (Though I failed to run s6.) What problems did you get with s6? It should be able to run without trouble. To me that's a more important issue than the ones you listed below. :) Here are the problems of skalibs: 1. In src/include/skalibs/nonposix.h, #if defined(__linux__) || defined(__GLIBC__) The if condition seems not working. Of course it's not __linux__, but I am using glibc. Ah, yes, __GLIBC__ is only defined in features.h, you're right. That is a problem, because features.h is not POSIX, so I can't rely on this file existing - especially in a header explicitly designed to gather workarounds to non-POSIXness. So #include is just not possible. And I can't #include any standard headers such as sys/types.h either, because the macros defined by skalibs/nonposix.h must appear *before* standard header inclusion. Do you have any idea on how to work around this? The only thing I can see is to #define _GNU_SOURCE (and other macros for other systems) unconditionally, but that's a bit annoying. I'll do it if there's no other solution though. 2. No PATH_MAX macro https://www.gnu.org/software/hurd/hurd/porting/guidelines.html Ugh, that's a tough one, and indeed relies on a very precise reading of the limits.h specification. I had no idea the limits defined in limits.h were optional; and they really shouldn't be. Dynamic allocation is much heavier than stack allocation and shouldn't be made mandatory. skaware relies on PATH_MAX, and a couple other limits, here and there; I can't promise I'll fix them all, especially if getting rid of PATH_MAX would introduce dynamic allocation in a place where there is currently none, or if it would require a change of public API. If you manage to build skaware on Hurd with -DPATH_MAX=4096, that's honestly good enough for me (and if things break when people have fun with longer absolute paths, that's on them and they can recompile with 8192 instead). What I can promise is to fix every issue that you might get with -DPATH_MAX=4096. And remove the dependencies on PATH_MAX that can be removed painlessly. How does that sound? -- Laurent
