diff options
Diffstat (limited to 'microkernel')
| -rw-r--r-- | microkernel/mach.mdwn | 4 | ||||
| -rw-r--r-- | microkernel/mach/deficiencies.mdwn | 17 | ||||
| -rw-r--r-- | microkernel/mach/external_pager_mechanism.mdwn | 12 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/building.mdwn | 28 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/debugging.mdwn | 41 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/memory_management.mdwn | 1 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/projects/mach_5.mdwn | 10 | ||||
| -rw-r--r-- | microkernel/mach/mig/documentation.mdwn | 1 | ||||
| -rw-r--r-- | microkernel/mach/mig/documentation/mig-mutate.mdwn | 138 | ||||
| -rw-r--r-- | microkernel/mach/mig/gnu_mig/building.mdwn | 4 | ||||
| -rw-r--r-- | microkernel/viengoos.mdwn | 4 |
11 files changed, 227 insertions, 33 deletions
diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index df1a3dab..3abb548d 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -24,9 +24,7 @@ microkernel currently used by the [[Hurd]]. # Implementations * [[GNU_Mach|gnumach]] - * [Apple's Darwin](http://developer.apple.com/darwin/) - ([API](http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html)) - (**non-free**) + * [Apple's XNU (Darwin)](https://github.com/apple-oss-distributions/xnu) (**non-free**) * [[open_issues/OSF_Mach]] diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index 8b137891..fcf86d79 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -1 +1,18 @@ +[[!meta copyright="Copyright © 2024 Free Software Foundation, +Inc."]] +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] + +* [[open_issues/resource_management_problems]] + +* [[IPC issues|microkernel/mach/gnumach/projects/mach_5]] + +* [[microkernel/mach/gnumach/projects/clean_up_the_code]] diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn index ccb72421..4bc863f1 100644 --- a/microkernel/mach/external_pager_mechanism.mdwn +++ b/microkernel/mach/external_pager_mechanism.mdwn @@ -39,10 +39,10 @@ is sent an [[exception]], which is normally further propagated as a segmentation fault. If there is an associated memory object, Mach checks whether the corresponding [[page]] is in core. If it is, it installs the page and resumes the task. Mach -then invokes the memory object with the `memory_object_request` +then invokes the memory object with the `memory_object_data_request` method and the page to read. The memory manager then fetches or creates the content as appropriate and supplies it to -Mach using the `memory_object_supply` method. +Mach using the `memory_object_data_supply` method. # Creating and Mapping a Memory Object @@ -120,7 +120,7 @@ mappings etc. (A) The client does a memory access and [[faults|page_fault]]. The kernel catches the fault and maps the address to the appropriate memory object. It -then invokes the `memory_object_request` method on the associated +then invokes the `memory_object_data_request` method on the associated capability. (In addition to the page to supply, it also supplies the control port so that the server can determine which kernel sent the message.) @@ -147,7 +147,7 @@ its own address space at the same time. (E) The storeio server transfers the page to the server. The page is still anonymous. -(F) The manager does a `memory_object_supply` transferring the page to +(F) The manager does a `memory_object_data_supply` transferring the page to the kernel. Only now is the page not considered to be anonymous but managed. @@ -174,8 +174,8 @@ if the server does not deallocate the page quickly enough, it cannot cause a denial of service: the kernel will just later double page it to swap (the default pager is part of the [[tcb]]). -(C) Mach then invokes `memory_object_return` <!-- doesn't exist --> method on the control -object. The server is expected to save the page free <!-- ? --> it in a timely +(C) Mach then invokes `memory_object_data_return` method on the control +object. The server is expected to save the page and free it in a timely fashion. The server is not required to send a response to the kernel. (D) The manager then transfers the data to the storeio server which diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index aed87046..b23985ac 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -19,16 +19,19 @@ enabled) is around 50 MiB. ## Getting the Source Code -You can either use the git repository (see <http://git.savannah.gnu.org/git/hurd/>), +You can either use the git repository (see <https://git.savannah.gnu.org/git/hurd/>), $ git clone https://git.savannah.gnu.org/git/hurd/gnumach.git/ + $ cd gnumach + $ autoreconf --install -... or get the Debian sources, if you're using Debian. (See +... or get the Debian sources to build a Debian package, if you're using Debian. (See [here](http://packages.debian.net/source/unstable/gnumach).) $ apt source gnumach + $ cd gnumach-XXXXXXXX -## On Debian Systems: +## Building a `.deb` package on Debian Systems: ### Preparing for the Build @@ -40,34 +43,29 @@ and some additional dependencies specified by the gnumach source package: ### Building and Installing ... Debian `.deb` files -Change into the directory with the downloaded / unpacked GNU Mach sources, +Start the build process with - $ cd gnumach-XXXXXXXX + $ dpkg-buildpackage -us -uc -b -Start the build process with +But to get it built faster, you probably want to only build the most common uniprocessor variant: - $ dpkg-buildpackage -us -uc -b -rfakeroot + $ dpkg-buildpackage -us -uc -b -Ppkg.gnumach.onlyup [[GNU_Mach|gnumach]] is now building. To use the new kernel, you must install the resulting `.deb` package which is located one directory above the build directory and has a similar name as the build directory: - # dpkg -i ../gnumach_XXXXXXXX-X_hurd-i386.deb + # dpkg -i ../gnumach-image-1.8-486_*_hurd-i386.deb You can now reboot your computer and enjoy the new kernel. -## On non-Debian Systems: +## Building from the git repository: ### Preparing for the Build Building GNU Mach requires a C compiler, a _static_ 32 bit standard C library, your favourite flavor of awk (gawk) and GNU make. -First, create the configuration files: - - $ cd gnumach - $ autoreconf --install - GNU Mach (and the associated headers) need be built in a separate build directory: $ mkdir build @@ -77,7 +75,7 @@ Run configure: $ ../configure --prefix= -If building on a 64 bit host system, +If building on a Linux 64 bit host system, you need a number of additional settings to force a 32 bit build: $ ../configure --prefix= --host=i686-gnu LD=i686-linux-gnu-ld CC=i686-linux-gnu-gcc diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index a134b618..bcff970e 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -73,6 +73,10 @@ and then type continue, to let Mach continue execution. The debugger will be ent struct db_watchpoint watch = { .task = NULL, .loaddr= 0x40e, .hiaddr = 0x40e+2, .link = NULL}; db_set_hw_watchpoint(&watch, 0); +To discover what an arbitrary address points to, try + + whatis 0x123400 + # GDB in QEMU When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly @@ -128,6 +132,43 @@ working directory. For example: ## [[open_issues/debugging_gnumach_startup_qemu_gdb]] +## Debug 64-bit gnumach + +[[build|microkernel/mach/gnumach/building/]] 64-bit gnumach with: + + $ export CFLAGS=-g + $ ../configure --enable-kdb ... + +run a spare Hurd vm (prepare for data loss in vm): + +* `kvm -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -drive file=$(echo debian-hurd*.img),cache=writeback -m 1G` +* `cd gnumach/build` +* `scp -P 2222 gnumach.gz user@127.0.0.1:/home/user/` +* You may copy `gnumach.gz` (also create new grub entry) or replace using `mv /home/user/gnumach.gz /boot/gnumach-xxx.gz` +* Shutdown vm. +* Append `console=com0` in boot menu and switch to console mode in qemu. (We have known issues with vga output for 64-bit.) +* You may load only required modules for debugging. +* `kvm -s -S -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -drive file=$(echo debian-hurd*.img),cache=writeback -m 1G` (note: `-s -S` added.) +* `gdb ./gnumach` +* `(gdb) target remote :1234` +* Press `c` to continue booting. + + +example `/boot/grub/grub.cfg`: + + multiboot /boot/gnumach-1.8-486.gz root=part:2:device:hd0 console=com0 + ... + echo 'Loading the Hurd ...' + module /hurd/ext2fs.static ext2fs --readonly \ + --multiboot-command-line='${kernel-command-line}' \ + \ + --host-priv-port='${host-port}' --device-master-port='${device-port}' \ + --exec-server-task='${exec-task}' -T typed '${root}' \ + '$(fs-task=task-create)' '$(task-resume)' + module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' + + + # Code Inside the Kernel diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn index 477f0a18..6eca2bce 100644 --- a/microkernel/mach/gnumach/memory_management.mdwn +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -13,6 +13,7 @@ License|/fdl]]."]]"""]] [[!toc]] +A related page is the [[open_issues/resource_management_problems]]. # IRC, freenode, #hurd, 2011-02-15 diff --git a/microkernel/mach/gnumach/projects/mach_5.mdwn b/microkernel/mach/gnumach/projects/mach_5.mdwn index 7b59170b..d7355f4b 100644 --- a/microkernel/mach/gnumach/projects/mach_5.mdwn +++ b/microkernel/mach/gnumach/projects/mach_5.mdwn @@ -54,11 +54,11 @@ rewrite rights and pointers to out-of-band memory, it has to parse the message. As type information and values are interleaved, it has to iterate over the whole message. -Furthermore, there are two kinds of type descriptors, mach_msg_type_t -and mach_msg_type_long_t. The reason for this is that the amount of -data that can be described using mach_msg_type_t is just 131072 byte. -This is because msgt_size is an 8-bit value describing the size of one -element in bits, and msgt_number is an 12-bit value describing the +Furthermore, there are two kinds of type descriptors, `mach_msg_type_t` +and `mach_msg_type_long_t`. The reason for this is that the amount of +data that can be described using `mach_msg_type_t` is just 131072 byte. +This is because `msgt_size` is an 8-bit value describing the size of one +element in bits, and `msgt_number` is an 12-bit value describing the number of items. ### Required change to the message format diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 740949e0..4c800e6b 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -85,6 +85,7 @@ pp. 67--77." * MIG *in action*: [[hurd/io_path]]. + * [[What is mig-mutate.h?|mig-mutate]] ## IRC, freenode, #hurd, 2013-09-04 diff --git a/microkernel/mach/mig/documentation/mig-mutate.mdwn b/microkernel/mach/mig/documentation/mig-mutate.mdwn new file mode 100644 index 00000000..dd027a04 --- /dev/null +++ b/microkernel/mach/mig/documentation/mig-mutate.mdwn @@ -0,0 +1,138 @@ +[[!meta copyright="Copyright © 2024 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The text in this page is based on the following code (from `$(hurd)/rtc/mig-mutate.h`): + + #define IO_INTRAN trivfs_protid_t trivfs_begin_using_protid (io_t) + #define IO_INTRAN_PAYLOAD trivfs_protid_t trivfs_begin_using_protid_payload + #define IO_DESTRUCTOR trivfs_end_using_protid (trivfs_protid_t) + #define IO_IMPORTS import "libtrivfs/mig-decls.h"; + +First, a brief description of what a protid is. Hurd translators +typically represent "files" internally with three kinds of distinct +structures: + +1. **node** -- these are filesystem nodes, same concept as an "inode". +2. **peropen** -- this keeps the data "per open" of the file and +corresponds to an "open file description" in POSIX. Things like +current I/O offset and the open mode (`O_READ | O_WRITE` ...) live here. +3. **protid** (or "credential") -- describes a specific "user" (UIDs/GIDs) +on behalf of whom the file is being accessed. + +A protid has a pointer to the peropen, and the peropen has a pointer +to the node. A node can have multiple peropens referring to it (when +the file has been opened multiple times), and a peropen can have +multiple protids referring to it (when processes running as different +users share an open file description, e.g. your shell and a sudo +invocation share the pts). In trivfs, there's only a single node, so +the concept is deemphasized. + +The concept of protid doesn't exist in classic Unix, since a +monolithic kernel can just directly see which UID the current process +runs as. But Mach IPC is (intentionally) designed in a way that it's +inherently impossible to see "who's asking", so instead we represent +differently-privileged callers with different handles (protids) that +refer to the same peropen, and then we check which protid the request +was made on. + +It is a protid that corresponds to an Mach port (`io_t`, `file_t`, ...), +though the client side doesn't need to care. + +When an incoming request arrives, the thing you actually receive in a +message is the port name (ignoring protected payloads for now). What +you actually want is the protid that it corresponds to. + +trivfs has the API to look up the protid given the port, namely +`trivfs_begin_using_protid` (which wraps `ports_lookup_port` from +libports), and you could call that yourself: + + kern_return_t + rtc_S_foobar (io_t port, int foo, int *bar) + { + error_t err = 0; + struct trivfs_protid *cred = trivfs_begin_using_protid (port); + + if (!cred) + /* The request came in on a port that we listen for incoming + * messages on, but it doesn't correspond to a protid. Must + * be some other kind of port. */ + return EOPNOTSUPP; + + if (!(cred->po->openmodes & O_READ)) + { + err = EBADF; + goto out; + } + + do something with cred... + + out: + trivfs_end_using_protid (cred); + return err; + } + +But since we already have a code generator (MIG), why not make it +generate the conversion logic for us as well. And so, in MIG, when +defining a type, you can provide `intran` and `outtran` and +`destructor` function names, and MIG will generate the calls for you. + +So the proper MIG way to (but see below about the Hurd way) to do the +thing that you're trying to do would be to define your own flavor of +Mach ports, say `rtc_port_t`, like this: + + type rtc_port_t = mach_port_t + intran: trivfs_protid_t trivfs_begin_using_protid (io_t) + destructor: trivfs_end_using_protid (trivfs_protid_t); + +and then use that type in the routine definitions. MIG would then call +`trivfs_begin_using_protid` and `trivfs_end_using_protid` in the server-side +generated functions, only passing `trivfs_protid_t` (which is a typedef +for `struct trivfs_protid *`, since MIG can't deal with the full C type +notation) to your implementation. The downside of this is that it the +implementation details of the server leak into the API definition, and +for instance you'd have to edit the `.defs` if you switch the server +from trivfs to netfs. + +You can find some documentation about this MIG feature under "Type +Translation Information" on page 17 of the [Mach 3 Server Writer’s +Guide](http://shakthimaan.com/downloads/hurd/server_writer.pdf), +but of course keep in mind that the guide was written a long time +ago, about a much older version of MIG, without any of the Hurd +additions/specifics/best practices. + +Then, `hurd_types.defs` has this: + + type io_t = mach_port_copy_send_t + #ifdef IO_INTRAN + intran: IO_INTRAN + intranpayload: IO_INTRAN_PAYLOAD + #else + #ifdef HURD_DEFAULT_PAYLOAD_TO_PORT + intranpayload: io_t HURD_DEFAULT_PAYLOAD_TO_PORT + #endif + #endif + #ifdef IO_OUTTRAN + outtran: IO_OUTTRAN + #endif + #ifdef IO_DESTRUCTOR + destructor: IO_DESTRUCTOR + #endif + ; + +(and same for all the other types of ports, e.g. `FILE_INTRAN`, +`SHUTDOWN_DESTRUCTOR` etc) + +which lets you use the standard `io_t` type while plugging in your own +`intran/intranpayload/outtran/destructor` functions, in a way that +doesn't leak into the `defs`. You only have to define the macros in your +local `mig-mutate.h` header in your server. + +The content in this page is from [bug-hurd mail list](https://mail.gnu.org/archive/html/bug-hurd/2024-11/msg00045.html) with some modifications. diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index e14c8fb0..eed12e03 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -84,10 +84,10 @@ configure: $ GNU=~/gnu $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" -If you are building on a 64 bit machine, you need to add a --host option: +If you want to build 32-bit gnumach on a 64-bit machine, you need to add a --target option. mig(com) will be build as ELF64 binary, but it will generate 32-bit stub code for gnumach: $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-gnu + $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --target=i686-gnu TARGET_CC=i686-linux-gnu-gcc Build and install the Mach Interface Generator into _$GNU_ (i.e. _~/gnu/_ in our example): diff --git a/microkernel/viengoos.mdwn b/microkernel/viengoos.mdwn index 66c6ff36..b8a588b9 100644 --- a/microkernel/viengoos.mdwn +++ b/microkernel/viengoos.mdwn @@ -23,10 +23,10 @@ to some of the [[issues_uncovered_by_the_Hurd|challenges]]. Knowledge gained can then be integrated into something like [[Mach]]. The source can be downloaded from the *viengoos.git* repository, cf. -<http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git>. You can +<https://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git>. You can check it out using, for example: - git clone git://git.sv.gnu.org/hurd/viengoos.git + git clone git://git.savannah.gnu.org/hurd/viengoos.git Then update to viengoos-on-bare-metal |