IRC channel logs
2026-07-02.log
back to list of logs
<Guest68>im trying to install Gentoo GNU Hurd, i cant find a stage3 however so im unsure of what to do <damo22>youpi: considering on xen cpus are swapped in and out by the hypervisor, is it even possible to cause an ast check on xen? <youpi>damo22: even if there's in/out by the hypervisor, the guest doesn't really see that, ast check is just like on a real cpu <azul_>in the gnumach, how is it separated the kernel heap from the rest of the memory? (in order to not overlap)? <azul_>is it there some work to be done in the gnumach? <damo22>azul_: yes, eg for SMP to figure out why user32 hangs <damo22>that is 64 bit gnumach with 32 bit userspace <azul_>how can be tested that setup?¿ <damo22>cross compiled with a forgejo runner <azul_>i mean ,debian gnu hurd has 32 bit and 64 bit, but for 64 bit with 32 bit userspace? <azul_>do you have a simple image that i can edit the gnumach source in? <damo22>azul_: see the topic for disk image <damo22>there is no need to have a complete user32 system to test gnumach with --enable-user32 you just run the make check test suite <azul_>so that image in the topic is a 32 bit userland with 64 bit gnumach? <damo22>as i said, you dont need the full user32 system to test it <damo22>you just get hurd-amd64 and compile gnumach with --enable-user32 etc, and then run the test suite <azul_>../configure does not list --enable-user32 <damo22>--disable-linux-groups --enable-user32 --enable-kdb <damo22>--disable-linux-groups --enable-user32 --enable-kdb --enable-ncpus=8 <damo22>that configuration currently hangs in gnumach <damo22>feel free to build it and test it <damo22>azul_: it will not boot but you could copy it to your host system and boot it in qemu <sneek>Welcome back solid_black, you have 1 message! <sneek>solid_black, azert says: I remember following Brent Baccala work on a libpager on steroids <azul_>qemu-system-x86_64: Cannot load x86-64 image, give a 32bit one. <azul_>the last thing it says is "HPET enabled" (with 1 cpu) <Alicia>probably after that and before whatever would be printed next <damo22>ah qemu hurd support is in the tree but not tagged yet <youpi>damo22: buildd doesn't do anything by itself, it's the qemu debian package maintainer who flags the architecture on which to build, and the buildd just obeys <youpi>it happens that the qemu debianp ackage maintainer is very hurd-friendly :) <azert>it’s a nice intro to libpager <solid_black>I am familiar with libpager (as the commit history might indicate :), I'm more of contemplating whether we even need it <azert>depends on what you want to achieve, right? <azert>ok but how much p9fs supports mmap? <azert>because you might wonder about keeping the fs consistent <solid_black>libpager would indeed bring a lot more benefit, maybe enough to pull its weight, if it handled multiple kernels/clients, like in Brent's experiments <solid_black>at the moment, 9pfs does not implement mmap at all, no <solid_black>I have some local changes to wire it up with libpager <azert>then I am not sure you should even implement it Hurd side <azert>I’d consider git behavior a bug instead <solid_black>but there can't and won't be the kind of coherence guarantees that a local on-disk fs gives you <solid_black>I want for executing binaries (and loading libraries) from 9pfs to work, and that definetely needs mmap <youpi>you can't fight the world on this :) <solid_black>assuming you do have rw access to a file, so you get a real port to the pager and not a proxy <solid_black>can you send it bullshit requests that will confuse libpager <solid_black>it does seem to check incoming control port against the single stored p->memobjcntl at least, and rejects requests with a different port <solid_black>the _data_ part in memobj RPC names is a confusing misnomer <solid_black>it makes you think in terms of supplying and receiving *data* <solid_black>anyway, if anyone wanted to pick up the work on distributed memory, the fundamental question that needs to be thought over is what to do about memobj proxies <solid_black>because currently it's pretty tied to the local kernel <solid_black>another issue with Mach's memobj API: there's no way to track which client of yours is faulting in a page <solid_black>such as for accounting purposes, you might want to record/log who changed a file <solid_black>but since you're forced to give out a single pager port to all your clients (modulo proxies), this info is lost <solid_black>a way this could work, for example, would be another level of indirection (not unlike protids vs peropens), where you'd give out different ports that all refer to the same memobj, and Mach would include the relevant port (that identifies the client responsible) with requests to the memobjs <solid_black>the part relevant for 9pfs is, we have to do reading/writing of the data as some user, but which one? when a file is opened, we have a protid, and know which user is requesting the I/O, but with mmap'ed pages we jjust know that a page should be read or written, but not who is responsible for it <solid_black>yet another thing, and this is partly on hardware rather than Mach, but: it would be cool to get "atomic access faults" in the same way that we get read/write faults <solid_black>without this, we have to conservatively synchronize access to pages: either a single machine can have writable access to the page, and everyone else cannot be even reading it <solid_black>so any sort of concurrent read/write access would turn into a lot of fighting for the page, tons of overhead and network traffic transferring the page contents back and forth <solid_black>but applications already *know* that they can't expect to see updates from concurrent writers instantly, unless they use appropriate memory synchronization (i.e. atomics) <solid_black>this was done for the benefit of locally-distributed memory (CPU core caches), but the same could be used to improve remotely-distributed memory access <damo22>ive almost done xen + smp but it needs gdt and idt for vcpus <damo22>youpi: can i mail it in with #warning to fix something <azul_>damo22, the problem seems to be that calibrate_lapic_timer(); and subsequent functions are called without interrupts enabled, and then the timer interrupts don't fire. and if you enable interrupts there, seems to hang otherwise <damo22>i cant finish xen+smp without a CI that can run xen <azul_>spl is 7 there, i dont know what that means <damo22>but the code is in much better shape than last time i submitted it <jab>So what are these "new-style structs" that I'm hearing about. Are we tweaking the Mach message format ? <jean-christophe>mach can run and communicate wih another mach kernel by translator ? <jean-christophe>ok it's time stop for this day, i hope hurd will become the reference... <azul_>damo22, I fixed it a bit after all, it now advances to usermode32, but then fails with a user_trap <azul_>although it works better with qemu-system-x86_64 than with kvm <azert>sneek later tell solid_black about the hardware improvement you mentioned such as remote atomic operations, I think that the most advanced NVIDIA data center network interface already implement them <azert>sneek later tell solid_black and all bypasses the kernel as well as the main cpu, since userspace normally talk with those nic directly using command queues