[matz@ruby-lang.org: Re: Porting to GNU/Hurd]
Good news! :-)
----- Forwarded message from Yukihiro Matsumoto <matz@ruby-lang.org> -----
From: matz@ruby-lang.org (Yukihiro Matsumoto)
To: wolfgang@pro-linux.de
Subject: Re: Porting to GNU/Hurd
Date: Fri, 18 Jan 2002 10:25:46 +0900
Hi,
In message "Porting to GNU/Hurd"
on 02/01/14, Wolfgang Jährling <wolfgang@pro-linux.de> writes:
|Of course, I would like to see future Ruby versions compile
|out-of-the-box on GNU/Hurd. While the patch I mentioned above would
|need to be ported to a current Ruby version (and I found one bug in
|the patch, which should be fixed), it gives a general picture of what
|kind of changed are neccessary. But since the biggest problem of the
|Hurd people is the lack of manpower, doing this makes only sense if we
|know that the patch will be accepted and included in the official
|version. Thus I wanted to ask you if you would accept such a patch.
Yes, as long as it does not hinder other part of Ruby.
|Some of the changes might look strange to you at first glance, which
|is the reason why I want to give some explanations:
|
|- The Hurd is a POSIX conforming system (modulo bugs). Thus the
| modifications are not really Hurd specific, but make Ruby conform
| better to the POSIX standard.
I understand that.
|- For example, POSIX says that PATH_MAX is optional; in the Hurd, we
| don't have PATH_MAX defined because we don't have such a limit. This
| means that using a character array of size PATH_MAX to store a file
| name does not work on the Hurd, instead one should use dynamic
| allocation. (Of course, we could #define PATH_MAX UINT_MAX or
| something like that, but this would cause a stack overflow in any
| application that uses PATH_MAX to calculate the size of an array.)
I'm in the process of removing PATH_MAX denedency. Someone
(I forgot the name, maybe Moritz) send me a patch to fix
this. But I didn't merge it because I didn't prefer
particular coding in it.
|- Many systems provide the array sys_errlist[] and the corresponding
| maximum offset sys_nerr (Ruby uses only the lattter), but these are
| neither POSIX nor ANSI. We have a good reason to not define them:
| Our current microkernel is Mach, and Mach uses the 6 most
| significant bits in an error constant to give information about the
| error system, some more bits for the subsystem, and the rest for the
| "real" value. Thus our errno constants start at 0x40000000. Using
| the sys_errlist[] array (and sys_nerr, since both belong together)
| would obviously be a bad idea here :-). Instead we only provide the
| strerror() function specified by POSIX. Rubys usage of sys_nerr
| would need to be removed.
Hmm, we need to find other way to handle system call related
exceptions. Let me think about it.
| A related issue is that since Ruby uses Fixnums to store the errno
| constants, the Errno::*::Errno values are wrong on the Hurd: The
| values are too big for a signed 31-bit integer.
This one is pretty easy to fix.
|There are several other issues, some of them similar to the ones
|mentioned above. If you have further questions, feel free to ask them.
|If I can't answer them myself, I will forward them to Hurd people who
|are more competent than me. I'd like to hear if you see any problems
|with accepting a patch that resolves these issues.
Send me patches. I'm positive about supporting Hurd.
matz.
----- End forwarded message -----
Cheers,
GNU/Wolfgang
--
Wolfgang Jährling <wolfgang@pro-linux.de> `-:._ "Omnis enim res, quae dando
Debian GNU/Linux user && Debian GNU/Hurd user `-:. non deficit, dum habetur
Hurd Hacking Guide - http://stdio.cjb.net/hhg.html ) et non datur, nondum
www.debian.org || www.gnu.org || hurd.gnu.org _,-:' habetur, quomodo habenda
["Accelerate your PC - with 9.81 m/s^2."] ,-:' est." --> fsfeurope.org <--
Reply to: