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: skarnet software license files
AFAIU skarnet software released under ISC License should include a license file in it's release tar files as ISC License expects to have a year and an owner mentioned in the license, isn't it? There is one. It's conventionally called COPYING. -- Laurent
skarnet software license files
Hi, AFAIU skarnet software released under ISC License should include a license file in it's release tar files as ISC License expects to have a year and an owner mentioned in the license, isn't it? Regards, Rodrigo Severo
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
