Age | Commit message (Collapse) | Author |
|
Add a helper library for attaching interrupt handlers in userspace.
Message-ID: <20240326045846.1661099-2-damien@zamaudio.com>
|
|
This reverts commit db46ea2eb9dc84959fbf9b1819facac3d6078ba1.
This is making the hurd startup hang.
|
|
This maps to EM_AARCH64. Just like the x86_64 branch, we only compile
this code if CPU_TYPE_ARM64 is defined in Mach headers, to avoid
raising Mach version requirement on other architectures; and we
explicitly enable the branch when building for AArch64 itself, to get
a build error if CPU_TYPE_ARM64 is somehow not defined.
Message-ID: <20240323115322.69075-7-bugaevc@gmail.com>
|
|
Message-ID: <20240323115322.69075-10-bugaevc@gmail.com>
|
|
Since no CPU subtypes are defined for CPU_TYPE_ARM64, just report the
type, same as for x86_64.
Sample uname(2) output:
sysname: GNU
release: 0.9
version: GNU-Mach 1.8/Hurd-0.9
machine: aarch64
Message-ID: <20240323115322.69075-9-bugaevc@gmail.com>
|
|
Message-ID: <20240323115322.69075-8-bugaevc@gmail.com>
|
|
The code here just wants to deallocate the whole address space, and Mach
already contains the logic to limit the passed-in range to the vm_map's
actual bounds (see VM_MAP_RANGE_CHECK).
Message-ID: <20240323115322.69075-6-bugaevc@gmail.com>
|
|
While GNU Mach on AArch64 still exports VM_MIN_ADDRESS / VM_MAX_ADDRESS
for compatibility, we should try to rely on it less when possible; in
the future we might be able to stop exporting them from Mach. The code
here really just wants to wire everything in its address space, and the
wire_segment_internal () routine already queries for actually present
memory regions dynamically.
Message-ID: <20240323115322.69075-5-bugaevc@gmail.com>
|
|
None of the new architectures are going to have it; that isn't specific
to x86_64.
Message-ID: <20240323115322.69075-4-bugaevc@gmail.com>
|
|
Not only on x86_64.
Message-ID: <20240323115322.69075-3-bugaevc@gmail.com>
|
|
The previous logic had two independent issues:
* We need to make the stack executable if either the program or its ELF
interpreter requires executable stack. In practice, it's common for
the program itself to not require executable stack, but ld.so (glibc)
needs it.
* mach_setup_thread () allocates stacks with a simple vm_allocate (),
which creates non-executable memory. So if an executable stack is
required, the stack has to be vm_protect'ed to enable execution, not
the other way around. As the comment suggest, it would've been better
to use vm_map () with the desired protection directly.
Message-ID: <20240323115322.69075-2-bugaevc@gmail.com>
|
|
struct bottomhalf.mdmstate is of type error_t (*)(int *state).
Fixes -Wincompatible-pointer-types, which is a hard error by default
in GCC 14.
Message-ID: <20240323115322.69075-1-bugaevc@gmail.com>
|
|
Message-ID: <20240312220842.79072-1-etienne.brateau@gmail.com>
|
|
Message-ID: <20240312220311.76709-1-etienne.brateau@gmail.com>
|
|
We are fine with only using xattr on filesystems that don't have the
i_translator inode field.
|
|
This allow to reduce the dependencies, only xkbcommon (keyboard support
only) is required instead of the whole x11 library + lex + yacc.
This replacement allow to reduce the code size, now features are handled
by xkbcommon itself.
The functionnalites remain the sames (actions are reimplemented
but in the code directly as it’s impossible to add custom actions).
The custom xkb data files are removed as we can now directly use the
standard ones from xkeyboard-config.
The configuration to launch the console keyboard modules changed to now
directly configure the model+layout+variat+options directly.
Tested by compiling with and without xkbcommon.
Tested X11 (ran i3 correctly).
Composing is still working.
Message-ID: <20240309234838.31923-1-etienne.brateau@gmail.com>
|
|
Message-ID: <20240309003840.586490-1-etienne.brateau@gmail.com>
|
|
block/char devices or directories
The perl test suite has a test where it reads all the block or char devices
under /dev without following the translators. Then it compares it against a
list of devices that read the translated nodes stat info.
The patch changes how the the device files are created initially so that the stat information
is identical and makes the Hurd environment appear more similar to other operating
systems.
Message-ID: <Zef__LrgPLXp9WHG@jupiter.tail36e24.ts.net>
|
|
Using vmstats allows to get up to 16T.
|
|
Replaces experimental option --x-xattr-translator-records
with --no-xattr-translator-records to allow rolling back to
previous behaviour.
NB:
- Legacy records still work with either setting.
- Adding a new record removes a legacy one.
|
|
|
|
Update argument types for sprint_frac_value to reflect how big they
actually are so that GCC doesn't think it needs a larger buffer than
necessary.
Message-ID: <ZeS1i5u_OziWpApt@jupiter.tail36e24.ts.net>
|
|
Userland might load BPF programs with unknown instructions, we currently
don't pre-check against that. In such a case, we shouldn't make netdde
completely abort, and rather just return 0 like e.g. in the division by
zero case.
|
|
Currently, if we do:
$ ls /dev/cd0/
The computer seems to get stuck, caused by the divide by 0 in the
rumpdisk server in device_get_status. I noticed that if we have no disk in the
cdrom device, we can still open it but block and media size will be 0
and the message "cd0 dos partition I/O error" will be printed to the
console. To avoid this problem, we check the block size and throw an error
when it is 0. This also works correctly when a disk actually exists.
This should help fix the perl and likely the vim test suites that are
currently failing in https://buildd.debian.org/.
Message-ID: <Zd_8XjcHcbNIp5NM@mars.tail36e24.ts.net>
|
|
Message-ID: <20240216182630.5770-2-flaviocruz@gmail.com>
|
|
|
|
In case the image was built through a tarball, /servers/socket/1 might
exist but not actually have been configured as pflocal translator. So
better check that we do have a translator there, and fix it otherwise.
|
|
Some systems have /bin/sh pointing to dash, which is even more stressful
for users when running in an emergency. Better first try bash. Also try
dash too in case /bin/sh is hosed.
|
|
This helps debugging boot issues.
|
|
|
|
emergency means we want to get a shell as quickly as possible, so we do
not want any daemon at all.
|
|
It has not been the kernel file name any more for a long time already.
|
|
|
|
Some systems have /bin/sh pointing to dash, which is even more stressful
for users when running in an emergency. Better first try bash. Also try
dash too in case /bin/sh is hosed.
|
|
So that people can install just dash.
|
|
for va_start etc.
|
|
Message-ID: <Za3wnF34kVU0r1TS@jupiter.tail36e24.ts.net>
|
|
* doc/hurd.texi (Special Files): added a reference to the zero store.
* doc/hurd.texi (Translators): added a sentence about /dev/random.
* doc/hurd.texi (Invoking 'mount'): added a short explanation.
* doc/hurd.texi (Trivfs Callbacks): added @code{FSTYPE_MISC}.
Message-ID: <20230921164822.9227-5-jbranso@dismail.de>
|
|
* doc/hurd.texi (FAT FS): new section.
Message-ID: <20230921164822.9227-4-jbranso@dismail.de>
|
|
* doc/hurd.texi (ISO-9960): I added in a short explanation.
Message-ID: <20230921164822.9227-3-jbranso@dismail.de>
|
|
* doc/hurd.texi (Linux Extended 2 FS): added a short description.
Message-ID: <20230921164822.9227-2-jbranso@dismail.de>
|
|
* doc/hurd.texi (Repairing Filesystems): described fixing filesystem
corruption.
* doc/hurd.texi (Shutdown): added the hurd specific halt-hurd command.
Message-ID: <20230921164822.9227-1-jbranso@dismail.de>
|
|
Message-ID: <ZZBGYmkYNwpoamBm@jupiter.tail36e24.ts.net>
|
|
Message-ID: <20231229212105.858759-11-flaviocruz@gmail.com>
|
|
Message-ID: <20231229212105.858759-10-flaviocruz@gmail.com>
|
|
Message-ID: <20231229212105.858759-9-flaviocruz@gmail.com>
|
|
Message-ID: <20231229212105.858759-8-flaviocruz@gmail.com>
|
|
Message-ID: <20231229212105.858759-7-flaviocruz@gmail.com>
|
|
This makes GCC happy.
Message-ID: <20231229212105.858759-6-flaviocruz@gmail.com>
|
|
Message-ID: <20231229212105.858759-4-flaviocruz@gmail.com>
|