IRC channel logs

<damo22>rrq: how is devuan / hurd different from hurd?

<damo22>as we dont use systemd at all, there could be no difference?

<rrq>yes. this concerns the forked packages and a could additional which you don't get with "pure debian".

<damo22>is there a list of the forked packages?

<damo22>why isnt it like a "port" or something rather than a hard fork?

<rrq>so the arithemtics is more (hurd + devuan) ... by adding sources.list point (see also https://dev1galaxy.org/viewtopic.php?id=7727)

<rrq>ACTION biab

<rrq>damo22: sorry I got distracted by some RL happening to me... and perhaps we should move further discussion to #devuan-hurd rather (?)

<damo22>ok

<damo22>youpi: when all_intrs is called and we are NOT interrupting from an interrupt, do we need to call swapgs or not? isnt this case an interrupt from kernel -> kernel so we dont need swapgs?

<damo22>or can we get an interrupt whilst in userspace?

<damo22>or do we assume: if we are not on an interrupt stack, we must have entered into the kernel via an interrupt from userspace so we NEED swapgs there

<damo22>aha kernel thread accessed user space on thread_sleep ((event_t) &info, simple_lock_addr(info.lock), FALSE);

<damo22>(gdb) n

<damo22>thread_invoke (old_thread=0x0, old_thread@entry=0xffffffffdc0edb40, continuation=continuation@entry=0xffffffff8105df50 <idle_thread_continue>, new_thread=0xffffffffdc0ed900) at ../kern/sched_prim.c:821

<damo22>821 thread_dispatch(old_thread);

<damo22>(gdb) n

<damo22>>>> kernel trap

<damo22>what does old_thread=0x0, old_thread@entry=nonzero mean?

<damo22>ah the old_thread was nonzero at entry to the function but at line 821 it was zero

<damo22>Switch_context has a bug!!! it overwrites %rax with the cpunumber

<damo22>so the continuation = cpu number

<damo22>or the thread is

<damo22>ok the only thing left to fix is GS

<damo22>WOW this could have a huge impact on amd64

<damo22>on hurd-amd64 currently, the Switch_context function is always returning 0

<damo22>so the idle thread is being called way more often than it shoudl

<azert>rrq: what you are doing is great because we need software ported to the hurd

<azert>but I don’t think we should split the community since it is already very small, let’s keep the discussion over here!

<azert>you noticed that there are some differences between the Hurd and Linux. Some of them are due to the fact that some parts of the Hurd predates Linux and are more close to BSD Unix

<azert>some are due to the fact that during the Unix wars the patching landscape was very fluid and lots identical code ended up in gnumach and BSD kernels

<azert>nowadays most of it is diverged

<rrq>azert: seems socat doesn't work sending UDP messages

<rrq>netcat-openbsd seems to do it

<rrq>but neither udp-sendto nor udp-datagram sends anything

<rrq>eg: echo hello | socat - udp-sendto:$IP:$PORT

<rrq>contrast: echo hello | nc -W1 -u $IP $PORT

<rrq>unix socket and tcp work but udo doesn't

<rrq>re not dividing the community: understood and agree.

<damo22>youpi: https://git.zammit.org/gnumach-sv.git/log/?h=smp64-upstream this branch almost works, but there is still a zero GS at startup of pci-arbiter, can you check the tip commit?

<youpi>I'm at work, I can't now

<damo22>ok no probs

<damo22>i wont make any more changes to my branch until tomorrow

<damo22>damn AI scrapers insist on fetching cgit one commit at a time

<nikolar>how else are they going to steal your code

<damo22>git clone?

<nikolar>lol no, that would be too smart and efficient

<nikolar>this is "ai" we're talking about

<damo22>riiihgt

<damo22>instead they open a new TLS connection every commit and suck data over https

<damo22>also they ignore robots.txt

<azeem>they take offense at being called a robot, they are androids

<nikolar>lol

<etno>I am trying to fix a library that makes use of ioccom.h when it is built for BSD like systems.

<etno>We have ioccom.h among the gnumach headers.

<etno>However, one part of the path of those headers includes the arch, like : /usr/include/x86_64-gnu/mach/x86_64/ioccom.h

<etno>What is the canonical way to refer to gnumach dev headers ?

<youpi>drop the x86_64-gnu part, /usr/include/x86_64-gnu/ is in the include paths

<etno>Yes, that part is handled correctly be the compiler

<etno>by*

<etno>It is the second "x86_64" part that I don't know how to handle

<youpi>that being said, it really depends what you want to do with it

<youpi>normally you would just use ioctl.h

<youpi>which will bring the IOC macros

<youpi>the hurd ones

<youpi>(the mach ones are not normally used)

<etno>Oh, that makes sense, let me try that instead

<youpi>there's a machine -> x86_64 symlink

<youpi>damo22: for the swapgs just before _kret_iret, it seems to me that it shouldn't be done when returning to kernel (returning from trap_from_kernel), so it should probably be just after TIME_TRAP_UEXIT

<youpi>in all_intrs, I don't think we know yet whether we are from user or kernel

<youpi>can't we just check the value of %ds against USER_DS, to know both at entry and exit whether we have to swapgs?

IRC channel logs

2026-01-08.log