Hello!
This is it -- my work on porting the Hurd proper to x86_64, and assorted
fixes that came up. I've split into separate patches by components for
ease of review.
Most of the changes amount to being more strict about integer types: we
can no longer use unsigned int, integer_t, size_t, vm_size_t, and
mach_msg_type_number_t all interchangeably. Whenever data is transferred
over Mach IPC, its size/count is mach_msg_type_number_t, not size_t. On
the other hand when an address or size is just sent or received in a
message as a value, its type is vm_address_t / vm_size_t (both are still
equivalent to size_t).
While in many cases this is simply a matter of fixing the type of a
variable, there also are places where we have to interface between the
APIs that are expressed in terms of mach_msg_type_number_t and ones that
use size_t's. In some places, it made sense to alter the APIs; the
principle that I was trying to follow is: when an API is meant to be a
more or less direct wrapper for a Mach RPC transferring data, it should
use mach_msg_type_number_t for the data size; but more generic APIs
should use size_t like the rest of the world does.
One annoying warning that I get a lot of when building the Hurd with
GCC 13 is -Wenum-int-mismatch; here's one example:
../../trans/streamio.c:694:1: warning: conflicting types for
‘trivfs_S_file_sync’ due to enum/integer mismatch; have ‘error_t(struct
trivfs_protid *, mach_port_t, mach_msg_type_name_t, int, int)’ {aka
‘error_t(struct trivfs_protid *, unsigned int, unsigned int, int, int)’}
[-Wenum-int-mismatch]
694 | trivfs_S_file_sync (struct trivfs_protid *cred,
| ^~~~~~~~~~~~~~~~~~
../libtrivfs/trivfs_fs_S.h:232:15: note: previous declaration of
‘trivfs_S_file_sync’ with type ‘kern_return_t(struct trivfs_protid *,
mach_port_t, mach_msg_type_name_t, int, int)’ {aka ‘int(struct trivfs_protid
*, unsigned int, unsigned int, int, int)’}
232 | kern_return_t trivfs_S_file_sync
| ^~~~~~~~~~~~~~~~~~
Other than just using -Wno-enum-int-mismatch, perhaps there is some
way we could tell GCC that this is very intentional that error_t is
used interchangeably with int and kernl_return_t?
Sp how much does actually build? Well, "all of it", but note that:
- I've disabled pfinet,
- I'm building --without-parted --without-libcrypt --without-libbz2
--without-libz --without-rump, so I haven't attempted to build anything
excluded by those switches.
But anyway, all of the libraries are getting built, and so are the most
important translators. I've tested ext2fs.static and (dynamically
linked!) exec, and the basic functionality seems to be working alright:
ext2fs discovers that it's the bootstrap fs task, initializes itself,
spawns the many worked threads, and resumes exec. exec starts up, doing
all the dynamic linking things, and in particular loading shared
libraries by RPCing to ext2fs; this means that:
- in general, the SHARED build of glibc is not fatally broken;
- pthread works;
- running multiple threads and tasks works in gnumach;
- basic filesystem stuff works;
- libports and libpager and libstore and libdiskfs and libihash and
libfshelp and libiohelp and libshouldbeinlibc all work;
- vm_map'ping works in gnumach.
Note that this also needs the gnumach patch to fix setting fsgsbase
when switching threads, and a glibc fix for starting pthreads. I'll
post both patches shortly, but not today.
The server bootstrap currently fails at
start ext2fs: Hurd server bootstrap: ext2fs[rd0] exec
Cannot find startup program `hurd/startup': No such file or directory
ext2fs: ../../libdiskfs/boot-start.c:274: diskfs_start_bootstrap: Unexpected
error: No such file or directory.
for me; for the simple reason that I have not put /hurd/startup into
my initrd. Lets maybe get a more complete Debian or crosshurd system
built, and see how far that takes us?
Sergey
