IRC channel logs

<damo22> The output from failed tests is collected in the test-suite.log file. If the variable ‘VERBOSE’ is set, this file is output after the summary.

<sobkas>nexussfan: it's a bit of a mess, it's bassed on git(newish version)

<sobkas> https://sobkas.github.io/mesa_26.0.0~devel-10.debian.tar.xz

<sobkas> https://sobkas.github.io/mesa_26.0.0~devel-10.dsc

<sobkas> https://sobkas.github.io/mesa_26.0.0~devel-10_source.buildinfo

<sobkas> https://sobkas.github.io/mesa_26.0.0~devel-10_source.changes

<sobkas> https://sobkas.github.io/mesa_26.0.0~devel.orig.tar.xz

<damo22>sobkas: rather than providing entire source, why not add a patch and upstream it?

<sobkas>There is: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39277

<sobkas>All that is needed to build it https://sobkas.github.io/mesa_26.0.0~devel-10.debian.tar.xz and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39277

<sobkas>Due to problems with sbuild on hurd, I use less sophisticated build method

<sobkas>damo22: I fixed a bit source code upload

<sobkas>Also why amd64 is 2x slower than i686?

<damo22>there is a change in gnumach i made recently that may increase speed, due to the switching contexts losing the %rax return value

<damo22>sobkas: try with more recent gnumach from source * 3d235455 x86_64/cswitch: Don't clobber %rax with cpu number

<sobkas>Oh, so which repo/branch I could use to build it?

<damo22>master

<damo22>git://git.savannah.gnu.org/hurd/gnumach.git

<sobkas>gnumach/gnumach-sv?

<sobkas>Ok, so I will try it tommorow, good night

<damo22>thank you for working on mesa

<damo22>i think it is unreasonable for ajax to expect you to port illumnos and haiku just because he doesnt want a different ifdef

<damo22>who wants to help debug this? https://code.zammit.org/damo22/gnumach-sv/actions/runs/27/jobs/13/attempt/1 its a problem with host_get_time64 MIG_TYPE_ERROR

<nexussfan>start ext2fs: ext2fs: gunzip:device:rd0: Invalid argument

<nexussfan>It's gonna be annoying to install hurd again...

<nexussfan>Never even heard of rd0

<youpi>it's ramdisk

<nexussfan>Oh

<nexussfan>Interesting

<youpi>there's a debian patch for the support

<nexussfan>Maybe it's cause I'm using ventoy

<youpi>it's waiting for somebody to clean it up for proper support

<nexussfan>Time to get a dvdrw

<nexussfan>Yup, ventoy was the problem

<damo22>youpi: how hard would it be to port qemu-system-x86 to hurd?

<damo22>i cant run the test suite from a hurd system

<damo22>the gnumach test suite

<nexussfan>Why exactly is it not built for hurd on buildd?

<damo22>well, i imagine kvm is not available

<nexussfan>qemu can run without kvm afaik

<damo22>could qemu networking spin up a second pfinet stack?

<nexussfan> https://code.zammit.org/damo22/gnumach-sv/actions/runs/27/jobs/13/attempt/1#jobstep-2-1699

<nexussfan>Not containerized?

<nexussfan>> make[1]: Leaving directory '/home/damo22/.cache/act/57b594d1426e4645/hostexecutor/build64'

<nexussfan>Yup

<damo22>so?

<nexussfan>Be careful

<damo22>nobody else is pushing code there

<damo22>its running in a vm anyway, you could delete root i dont care

<nexussfan>Oh

<nexussfan>How can I install OpenJDK for Hurd? I've heard it's ported but not sure how to run it on Debian/Hurd

<damo22>its not ported afaik

<nexussfan> https://darnassus.sceen.net/~hurd-web/user/jkoenig/java/

<nexussfan>> OpenJDK 7 kindof works, but there are still imperfections and some integration work remains.

<damo22>i re-added gcj 6.5.0 to hurd debian

<damo22>so you have a java compiler to bootstrap with

<damo22>i wanted to port openjdk 8

<nexussfan>Nice, Hurd booted on my T43

<damo22>why not try a x200

<nexussfan>I don't have that

<damo22>did you buy the t43 especially for hurd?

<nexussfan>No

<nexussfan>Also the keymap is a bit weird

<damo22>ok

<nexussfan>pressing the button next to 0 does _

<nexussfan>not -

<nexussfan>Oh wait

<damo22>capslock?

<nexussfan>It's just capslock being broken on hurd like usual

<damo22>nexussfan: if you could compile openjdk7 that would be cool

<damo22>then we could add it to debian

<damo22>and use it to try to port openjdk8

<nexussfan>Well it says that it's ported

<damo22>yeah

<damo22>7

<nexussfan>True

<nexussfan>Maybe I can use netcc on my 2 machine hurd """cluster"""

<damo22>but you could attempt to compile the source on latest hurd

<damo22>using gcj6

<damo22>if it works, we have a way to bootstrap java on hurd

<nexussfan>I've never really compiled java

<nexussfan>+ there's no src package for it anymore

<damo22>deb-src http://jk.fr.eu.org/debian experimental/ ?

<nexussfan>> jk.fr.eu.org’s server IP address could not be found.

<damo22>:(

<nexussfan>Sad

<nexussfan>Maybe you can contact the dev

<damo22> https://github.com/jeremie-koenig/jdk7-hotspot

<nexussfan>Nice

<damo22>go forth and compile the source

<damo22>nexussfan: it was forked from https://github.com/openjdk-mirror/jdk7u-hotspot/tree/jdk7u2-b01

<damo22>so that is the base of his repo

<damo22>Import upstream revision 2560:9b0ca45cd756

<damo22>so you could get his changes and rebase them onto latest jdk7 version

<nexussfan>Needs J2SE

<nexussfan>`/bin/sh: 3: /java/re/j2se/1.6.0/latest/binaries/linux-i586/bin/java: not found`

<nexussfan>LOL

<damo22>nah

<damo22>JAVA_HOME?

<damo22>you need gcj-6

<nexussfan>Oh ok

<damo22>youpi: some interesting failures with full smp (no slave pset) https://code.zammit.org/damo22/gnumach-sv/actions/runs/28/jobs/5/attempt/1#jobstep-2-1675

<damo22>mach_msg is not smp safe?

<damo22> switch (self->ith_wait_result) {

<damo22> case THREAD_INTERRUPTED:

<damo22> /* receive was interrupted - give up */

<damo22>why does ipc_mqueue_receive() give up if the rcv was interrupted?

<damo22>surely it can be interrupted

<damo22>ah the caller calls it in a loop if it returns MACH_RCV_INTERRUPTED

<damo22>thread_set_syscall_return(thread, MACH_RCV_INTERRUPTED);

<damo22>doesnt that mean every mach_msg RPC could return that?

<damo22>so all callers of the mach_msg need to handle if it was interrupted?

<damo22>ok the tests are not thread safe

<youpi>damo22: iirc somebody gave a stab and got something to work and it was essentially the usual PATH_MAX stuff. kvm acceleration is however some beast, of course

<youpi>damo22: yes, glibc takes care of restarting rpc calls

<youpi>see glibc/hurd/intr-msg.c

<youpi>tests have been written only lately, so they didn't care about thread safety indeed

<damo22>but the tests dont run libpthread or glibc?

<youpi>yes, so they need to care about rpcs possibly getting interrupted, and restart them

<damo22>i see

<damo22>can i use a semaphore for test-machmsg to wait for the thread to get interrupted and then terminated?

<youpi>you can use gsync

<damo22>ah ok

<damo22>can i remove thread_terminate from recv_to_be_interrupted in test-machmsg.c? if the function returns what will happen to the thread?

<damo22>the rest of the caller seems to already suspend/abort/resume the thread

<damo22>i dont see the point of the race induced

<youpi>? you do want to call thread_terminate at the end of a thread function

<youpi>to catch any issue that'd prevent it from terminating otherwise

<youpi>rather than return to 0

<damo22>i dont understand the test then, what is thread_{suspend,abort,resume} for in the caller?

<youpi>I was speaking generally: you do want a nice print+exit rather than a odd general protection fault because of returning to 0

<youpi>now, in the case of recv_to_be_interrupted, apparently it tests that mach_msg properly returns the appropriate error on interruption

<youpi>it's the thread_abort() call that interrupts the rpc

<damo22>oh

<damo22>msleep(100) is not ideal way to wait for thread to half receive though

<youpi>sure

<youpi>but the system is essentially idle otherwise

<youpi>so it should really be effective

<damo22>it breaks on smp

<damo22>(with full smp)

<youpi>what is the symptom?

<damo22> https://code.zammit.org/damo22/gnumach-sv/actions/runs/28/jobs/5/attempt/1#jobstep-2-1674

<damo22>it gets the interruption, mach_msg returns correct error code but when something tries to check thread its null?

<youpi>?

<youpi>the error is inside wait_thread_terminated

<youpi>which just gets information for a thread, until it gets an error

<youpi>it should indeed either succeed, or get MACH_SEND_INVALID_DEST

<youpi>anything in-between is odd

<youpi>be it smp or not

<youpi>you can add prints inside thread_info() to check why it says the argument is valid (and not the dest)

<damo22>good idea

<damo22>heh putting the prints made it pass

<sobkas>damo22: Using master git branch didn't changed anything

<sobkas>But I see that pflocal is using 50-60% of cpu when glxgears is running

<sobkas>On 32bit mesa build takes 15m 16s

<sobkas>While on 64 14m 13s

<sobkas>So 64bit is faster, but glxgears are still faster on 32bit ~200fps, vs 64bit 110fps

<damo22>are you using --enable-apic on 32 bit or not

<damo22>i think interrupts are slower on apic in general than pic

<sobkas>It's configured same as default debian package(used ./debian dir)

<sobkas> https://www.gnu.org/software/hurd/open_issues/pflocal_x_slowness.html

<sobkas>But I see pflocal is using lots of cpu on 64bit

<sobkas>When glxgears is running

<sobkas>damo22: is there an easy way to profile pflocal?

<youpi>sobkas: there is a hurd-prof package that contains -pg -compiled binaries

<gnu_srs>sobkas: I still get the memory error on i386. Did you patch mesa-demos package?

<sobkas>gnu_srs: No I have same mesa-utils on both 32 and 64 bits

<sobkas>But I use experimental/sid

<sobkas>youpi: How to use this package to produce profile output files?

<sobkas>Replacing pflocal with pflocal.prof and starting system didn't helped

<gnu_srs>sobkas: mesa-demos_9.0.0-2, mesa_25.2.8-2

<sobkas>gnu_srs: I have mesa-utils: 8.4.0-2

<sobkas>mesa 25.3.3 and now git

<sobkas>There are binaries that you can compare with yours

<gnu_srs>Same crash with mesa-utils: 8.4.0-2. How much memory have you given qemu?

<gnu_srs>Did you rebuild xserver/xorg after installing mesa?

<azert>sobkas: you will need to run the translator with gprof

<azert>check a tutorial!

<sobkas>gnu_srs: I gave 32bit machine 3027MiB and I only build mesa

<sobkas>azert: Tutorial?

<sobkas>Was looking for one never found any

<sobkas>gnu_srs: https://paste.debian.net/hidden/905a6c99

<sobkas>gnu_srs: what cpu you have on 32bit machine?

<gnu_srs>default

<sobkas> https://paste.debian.net/hidden/229db4a3

<gnu_srs>you mean the host cpu?

<sobkas>I have host-passtrough configured for both 32bit and 64bit

<gnu_srs>qemu-system-x86_64 -enable-kvm -m 3072 -net nic,model=e1000 -net user,hostfwd=tcp::5577-:22 -drive cache=writeback,index=0,media=disk,file=hurd.img

<sobkas>Ok:

<sobkas>t":"raw","file":"/var/lib/libvirt/qemu/domain-18-hurd-i386/master-key.aes"} -machine pc-i440fx-10.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=on,acpi=on -accel kvm -cpu host,migratable=on -m size=3099648k -object {"qom-type":"memory-backend-ram","id":"pc.ram","size":3174039552} -overcommit mem-lock=off -smp 4,sockets=1,dies=1,clusters=1,cores=2,threads=2 -uuid d53504cc-b9f9-4694-8658-80404c78be51 -no-user-config -nodefaults -chardev

<sobkas>socket,id=charmonitor,fd=36,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device {"driver":"ich9-usb-ehci1","id":"usb","bus":"pci.0","addr":"0x5.0x7"} -device {"driver":"ich9-usb-uhci1","masterbus":"usb.0","firstport":0,"bus":"pci.0","multifunction":true,"addr":"0x5"} -device

<sobkas>{"driver":"ich9-usb-uhci2","masterbus":"usb.0","firstport":2,"bus":"pci.0","addr":"0x5.0x1"} -device {"driver":"ich9-usb-uhci3","masterbus":"usb.0","firstport":4,"bus":"pci.0","addr":"0x5.0x2"} -device {"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.0","addr":"0x6"} -blockdev {"driver":"file","filename":"/var/lib/libvirt/images/hurd-i386.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-

<sobkas>1-format","read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-1-storage","backing":null} -device {"driver":"ide-hd","bus":"ide.0","unit":0,"drive":"libvirt-1-format","id":"ide0-0-0","bootindex":1} -netdev {"type":"tap","fd":"38","id":"hostnet0"} -device {"driver":"e1000","netdev":"hostnet0","id":"net0","mac":"52:54:00:20:d9:f0","bus":"pci.0","addr":"0x3"} -chardev pty,id=charserial0 -device {"driver":"isa-serial","chardev":"charserial0","id":"ser

<sobkas>ial0","index":0} -chardev spicevmc,id=charchannel0,name=vdagent -device {"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"com.redhat.spice.0"} -device {"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"} -audiodev {"id":"audio1","driver":"spice"} -spice port=5901,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on -device {"driver":"qxl-vga","id":"video0","max_outputs"

<sobkas>:1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pci.0","addr":"0x2"} -device {"driver":"intel-hda","id":"sound0","bus":"pci.0","addr":"0x4"} -device {"driver":"hda-duplex","id":"sound0-codec0","bus":"sound0.0","cad":0,"audiodev":"audio1"} -chardev spicevmc,id=charredir0,name=usbredir -device {"driver":"usb-redir","chardev":"charredir0","id":"redir0","bus":"usb.0","port":"2"} -chardev spicevmc,id=charredir1,name=usbredir

<sobkas>-device {"driver":"usb-redir","chardev":"charredir1","id":"redir1","bus":"usb.0","port":"3"} -device {"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x7"} -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

<sobkas>It looks bad

<sobkas>But couldn't push it into paste.debian.net

<sobkas>So how to start pflocal.prof to get profiling info?

<sobkas>replacing /hurd/pflocal didn't produced any output files

<bjorkintosh>has anyone installed hurd on proxmox yet?

<bjorkintosh>I keep getting 'no installation media found'.

<nexussfan>Like installing Hurd in a VM inside proxmox? I don't use proxmox much so i'm not sure how it works

<bjorkintosh>it's based on qemu

<nexussfan>Then it should work

<bjorkintosh>should.

<nexussfan>No installation media in the debian installer or in bios?

<nexussfan>like when debian installer tries to detect the cd

<nexussfan>or when seabios/whatever loads the cd

<bjorkintosh>debian is getting stuck.

<nexussfan>oh

<nexussfan>Weird

<bjorkintosh>I know it's /dev/ide2 but it doesn't accept it.

<nexussfan>You know that there's a qemu preinstalled image for hurd, right?

<bjorkintosh>where is it?

<bjorkintosh> https://www.debian.org/ports/hurd/hurd-cd this is where I've been looking so far.

<nexussfan>Do you want amd64 or i386?

<bjorkintosh>amd64

<nexussfan>Okay]

<nexussfan> https://cdimage.debian.org/cdimage/ports/stable/hurd-amd64/debian-hurd.img.tar.gz

<nexussfan>Keep in mind that this is a frozen image which does not get security updates

<nexussfan>for a debian/hurd install which uses sid you can use:

<nexussfan> https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/debian-hurd.img.tar.gz

<bjorkintosh>alright I'll try it and see.

<bjorkintosh>eh. no luck with either image.

<bjorkintosh>probably something I need to fuck around with for a bit.

<nexussfan>Yeah

<nexussfan>> hd2: packet command error

<bjorkintosh>how are you running hurd, nexussfan?

<nexussfan>I am running it on real hardware on a T43 and T420

<nexussfan>My hurd t43 machine is outputting a lot of `hd2: packet command error` things at boot but it still runs

<nexussfan>I don't know why

<nexussfan>I don't even use the hd2 slot

<bjorkintosh>well. hurd is still experimental isn't it?

<nexussfan>Yes

<nexussfan>weird, everyone says i386 hurd is better but in my experience it's been worse

<bjorkintosh>I've restarted the installation afresh with defaults only on the hardware, and it seems to be progressing with the iso.

<bjorkintosh>fingers finging right now.

<nexussfan>another thing annoying: once you start X then you can't switch virtual terminals

<sobkas>You already lost at "start X" part

<nexussfan>X works perfectly fine :P

<nexussfan>Well, good enough

<nexussfan>I'll probably just delete xdm for now

<bjorkintosh>sobkas: is wayland already working on hurd?

<nexussfan>No, as wayland requires DRM

<nexussfan>HURD has no DRM support

<sobkas>In theory adding hurd support to libgbm should solve problem, but in practice yes DRM is only option for now

<nexussfan>Also that

<nexussfan>But if we do tht we also get mesa support

<sobkas>And most of wayland compositors use libinput, and for now I don't know about hurd supporting libinput

<nexussfan>You could make your own wayland compositor 🤔

<nexussfan>I'd like to imagine there's no hard requirement for libgbm/DRM in the spec

<sobkas>wayland compositor is just glorifed buffer pusher, I bet there is already one that do framebuffer

<nexussfan>Exactly

<bjorkintosh>is it that easy to create a compositor?

<nexussfan>Muffin is a good start

<nexussfan>It barely supports any of the spec

<bjorkintosh>way beyond my paygrade.

<nexussfan>So it may be portable

<nexussfan>Depends on how many SLOC there is

<sobkas>I have plan to move hurd-console to evdev and have libevdev/libinput support for almost free, but now I'm busy with mesa

<nexussfan>Mesa is more important

<nexussfan>Wayland can wait

<sobkas>Then split hurd-console into evdevd and kmsdrmd

<sobkas>and use kmscon for console

<bjorkintosh>alright hurd is installed.

<bjorkintosh>it looks no different from a regular *nix install

<youpi>sobkas: -pg -enabled binaries produce a gmon.out file on exit, you can process it with gprof

<sobkas>I have moved pflocal.perf in place of pflocal and and after two restarts it didn't produced any output

<youpi>you need to make it exit, with a settrans -g for instance

<youpi>try with a normal program for a start ,to understand how gprof works

<sobkas>Isn't pflocal exit/get killed at shutdown/reboot? I was thinking at that point it should create output file

<bjorkintosh>alright. hurd's installed. what're some neat things it can do?

<youpi>bjorkintosh: you have the wiki hurd primer page

<bjorkintosh>translators

<sobkas>settrans -g /servers/socket/1

<sobkas>settrans: /servers/socket/1: Device or resource busy

<bjorkintosh>is there a book on hurd?

<youpi>sobkas: you have a -f option

<youpi>bjorkintosh: there's the whole wiki

<bjorkintosh>ah it's based on MACH isn't it?

<bjorkintosh>that's great.

<azert>sobkas: your plan on the Hurd console looks very pretty but once you carefully analyze it you’ll realize you want to just move stuff around for just a bit of cross-compability with Linux.

<azert>oh he left

<nexussfan>There's a pretty small wayland compositor called tinywl

<bjorkintosh>does hurd interact with the gui differently?

<nexussfan>You can use X on Hurd

<nexussfan>The only "DE" is IceWM

<bjorkintosh>well, the way plan9's gui is different from anything else out there.

<bjorkintosh>hurd sounds like a drop-in replacement for regular old *nix stuff.

<nexussfan>Yes, hurd is a unix like kernel

<bjorkintosh>that's cool.

<nexussfan>Because GNU's not Unix!

<bjorkintosh>never.

<sobkas>azert: being able to use libevdev and libinput is not a small thing

<sobkas>I tested pflocal.prof, killed it started it again and I did it several times, no gmon.out or any *gmon* file

<sobkas>Killed with settrans -fg

<sobkas>Any normal binary compiled with -pg produces gmon.out

<bjorkintosh>no manual for settrans?

<nexussfan>There's no manpage?

<bjorkintosh>not that I can find.

<bjorkintosh>curious. the standard editor isn't installed by default either.

<nexussfan>ed?

<bjorkintosh>it's not there.

<nexussfan>Wow

<bjorkintosh>nano's there though.

<sobkas>I also didn't see any, but as in free software you can always write one

<nexussfan> https://www.gnu.org/fun/jokes/ed-msg.html

<bjorkintosh>emacs is installed by default.

<nexussfan>The best editor

<bjorkintosh>it's been great.

<nexussfan>It's the reason why hurd is daily drivable

<nexussfan>it has web, email, editing, so much

<sobkas>web?

<nexussfan>Emacs Web Wowser

<bjorkintosh>sobkas: as you know, in every bare metal OS, there are other OSes using it as a host. emacs is one of those, and browsers are yet another.

<sobkas>Well I only see luakit

<sobkas>but to be honest I'm tempted to try exwm

<bjorkintosh>is there a config tool built in

<nexussfan>Oh, luakit works on Hurd? Epic!

<azert>sobkas: are you sure you are using the executable compiled with -pg?

<azert>readelf or objdump should tell you

<azert>also beware that the translators working directory is the same as the process that started them. The gmon file should end up there

<azert>sobkas: would be better if the hurdish libevdev and libinput will be able to use a usb keyboard

<sobkas>Ok, I'm close to working sbuild

<nexussfan>How come `reboot` properly reboots the system but `halt` doesn't properly turn off the computer

<youpi>because halt is not supposed to turn off a computer

<youpi>poweroff is

<nexussfan>I'll try it

<nexussfan>Nope

<nexussfan>`poweroff` doesn't work either

<nexussfan>It just says Entering sleep state

<youpi>is that on real hardware?

<nexussfan>Yes

<youpi>acpi is a beast

<youpi>so I'm not surprised

<damo22>it should be setting sleep state S5

<nexussfan>Yes it does

<nexussfan>But after that message

<nexussfan>Nothing happens

<damo22>hmm

<nexussfan>On both i386 T43 and x86_64 T420

<nexussfan>Only in qemu it turns off correctly

<damo22>that used to be the case for sure before we ported acpica

<damo22>but it should be parsing the sleep methods

<damo22> * DESCRIPTION: Enter a system sleep state via the legacy FADT PM registers

<damo22> * THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED

<damo22>maybe cli is missing

<nexussfan>Should we drop the `libwayland-dev:hurd-amd64` for redshift?

<nexussfan>For now, of course

<nexussfan>Because there's no wayland support

<damo22>youpi: should i add a mach rpc for clearing interrupt flag?

<damo22>or irq device rpc?

<azert>sobkas: of course I don’t want to sound dismissive, would be great to have the Hurd api be most similar to Linux as possible because Linux developers made great stuff that would be nice to port over.

<nexussfan>Somewhat

<azert>from what I saw, keeping up with Linux is impossible

<azert>and they are going to come up with more and more incompatible solutions

<nexussfan>That sounds like the Linux I know

<youpi>damo22: that cannot be a simple rpc, since the generic return-to-user will re-enable interrupts

<youpi>it really has to, to be sure to get back clock interrupts etc.

<youpi>now, there is the iopl() system call on linux that allows userland to call cli

<youpi>that could be added

<nexussfan>azert: Hopefully once we have enough Hurd devs then we can start writing our own stuff for hurd

<azert>nexussfan: I agree that would be the way

<azert>to go

<nexussfan>Right now we are using rump, small pieces of linux, random other softwares, etc.

<damo22>youpi: does that change the ring of userspace

<youpi>nexussfan: that's way less things to maintain

<youpi>damo22: yes

<nexussfan>youpi: True, I guess :P

<azert>I think that code reuse is great when it is feasible

<nexussfan>Also you run into licensing issues somewhat

<damo22>im not sure that is a secure feature to be adding

<azert>not with bsd code, but with Linux there is a risk

<nexussfan>True

<youpi>damo22: it's not, but whenever you have host access you can do a lot anyway

<youpi>licensing: the hurd is precisely where it's less a concern since you can run things in separate processes

IRC channel logs

2026-01-24.log