IRC channel logs

<jab>yang3: have you started the upgrade?

<jab>definitely do it on the console

<jab>NOT in X

<jab>also make sure you update via:

<jab> # apt upgrade --without-new-pkgs

<jab> # apt full-upgrade

<youpi>(as documented)

<yang3>jab I did exactly that, and it finished, hoping for a safe reboot now

<yang3>it upgraded without errors

<yang3>i did it over ssh

<yang3>computer screen matrix is worn out, it barely has any light

<yang3>but I can always plug in the external monitor

<jab>cool

<yang3>it came back as "GNU hurd 0.9 GNU-Mach 1.8+git20260224-up-486/Hurd-0.9 i686-AT386 GNU"

<yang3>ps auxw (works), but ps wuxa (doesnt)

<damo22>youpi: does PV-grub run as dom0?

<damo22>that would be kind of cool if grub itself could be the dom0

<damo22>that would remove the linux dependency

<youpi>damo22: no

<youpi>again, dom0 needs to be running some management tools

<youpi>such as the xenstore etc.

<youpi>it also provides hardware access (disk/network)

<damo22>youpi: from what i read about pvgrub2 it starts in dom0 and can load a lower privileged xen guest

<youpi>no it starts inside the domU

<youpi>that's the whole point of pvgrub, running from within the guest

<youpi>(not to be cofused with pygrub which indeed runs inside dom0, thus a security risk)

<Zhou-Yutao>Hi all, I'm Zhou-Yutao. Finally made it in.

<azul_>hello

<damo22>Zhou-Yutao: your IRC client keeps disconnecting

<azul_>i think i still have, damo22 the thing i debugged

<damo22>i dont recall

<azul_>for user32 to work in 64 bit mach

<azul_>up to a point

<damo22>ok

<azul_>at least to the loading of the modules

<damo22>i think mig is broken on i386

<azul_>it was the interrupts

<damo22>as well

<azul_>mig for i386

<azul_>or mig user32 for amd64

<damo22>the interfaces it generates on 32 bit are not consistent

<azul_>why is so difficult to generete them?

<azul_>generate

<damo22>but we cant change them now

<azul_>i suggest to remove mig from the design

<azul_>we are still in tiome

<azul_>time

<azul_>after much more implementation would be harder

<azul_>i sell my ipc to hurd

<damo22>user32 is broken specifically because the 32 bit interfaces have different struct member sizes than the actual structs

<azul_>so that a mismatch

<azul_>that is too hardcoded

<azul_>why do you hardcode messages?

<Zhou-Yutao>My internet connection here is not very good, it keeps disconnecting

<azul_>which type of connection is it?

<Zhou-Yutao>On the web page, my device is currently connecting to a VPN

<azul_>and outside the vpn?

<damo22>the mach interface generator is supposed to generate interfaces that are compatible with the data being sent but unfortunately i think there were changes that were made for structs in particular that made it not compatible anymore

<damo22>youpi: is it possible we can fix it without rebuilding all of world?

<Zhou-Yutao>Unable to connect to libera.chat due to special restrictions imposed on Chinese Mainland

<azul_>i mean, is it fiber, cable, mobile, ?

<Zhou-Yutao>Under these circumstances, I can only connect through a VPN

<azul_>coaxial, twister pair, ...

<Zhou-Yutao>Yes, this is mobile

<youpi>damo22: see the mail I have just sent

<youpi>I believe it is not wrong, it does match the C semantic

<azul_>me also, Zhou-Yutao

<youpi>user32 just has to cope with the fact that 64b and 32b don't have the same alignment requirements

<damo22>interesting

<azul_>and what you do in the hurd, Zhou-Yutao?

<youpi>azul_: there is no hardcoding, on the contrary, it's based on a common .defs definition

<youpi>the concern is the proper translation between the 32b interpretation and the 64b interpretation of it

<Zhou-Yutao>Just exploring for now. I'm interested in the microkernel design and how Hurd handles IPC.

<azul_>why don't you remove those restrictions?

<azul_>that is complicated, youpi

<azul_>what do you need those hardcoded interfaces (even in .defs) for?=

<damo22>youpi: why does alignment of struct matter for sending contents of structs?

<damo22>if it knows there is a 64b value there, it can read it out and then send it as a unit

<youpi>azul_: that's not a restriction, on the contrary

<youpi>damo22: because the stub function is given the adress within the mig message, so it has to have the proper alignment

<youpi>the *server function I mean

<azul_>why don't you to ipc a-la-tcp-udp-ip?

<azul_>streams of bytes or packets

<youpi>because it's slow?

<youpi>and doesn't actually provide the features we need

<azul_>slow?

<youpi>yes

<azul_>that are you saying?

<youpi>way slower than direct kernel messages

<youpi>you don't seem to actually understand what we are talking about

<azul_>unix domain sockets are slow?

<youpi>unix domain sockets are not tcp/ip

<azul_>direct kernel messages you say

<youpi>and still, unix domain sockets don't provide the features we need

<azul_>i said a-la-tcpip, not tcpip

<azul_>which ones dont they provide?

<youpi>what tcp-ip feature you'd want?

<azul_>you thing do you need them?

<azul_>none

<youpi>port sets, send-once, etc.

<youpi>please do read about things before proposing replacements

<azul_>i mean, streams of bytes or streams with limits

<youpi>you can't propose something without knowing what we need

<azul_>what do you need hten?

<youpi>we don't need streams for ipc

<youpi>that's useless

<azul_><youpi> port sets, send-once, etc.

<azul_>ok

<azul_>you think so

<azul_>you dont study the field as much

<damo22>lol

<azul_>yes yes

<azul_>easy to type

<damo22>azul_: cmon man hes the maintainer

<azul_>that three letters

<azul_>yes yes

<damo22>he knows a little more than you give credit for

<azul_>maintainer?

<azul_>maybe designer

<azul_>mantainer are youy

<azul_>which he?

<azul_>you maintain yes

<azul_>i know

<azul_>what others designed

<azul_>and you dont know how to change

<damo22>azul_: are you on drugs?

<azul_>resort to that, clever boy

<damo22>anyway we are talking about mig

<damo22>i wasnt sure why the alignment matters

<damo22>apparently the mach message is addressable

<damo22>that changes a lot

<damo22>but if the msgs are addressed how can they not all have to be packed structs?

<youpi>why packing?

<azul_>so come close to unix domain sockets (address messages, less hardcoded) you learned a bit, yes

<youpi>the mig types do provide the alignment requirements, and thus give knowledge of possible holes

<damo22>if packed, the alignment wont matter again

<youpi>alignment always matter on some archs

<youpi>you just can't always pack completely :)

<damo22>ah

<damo22>so if _alignof__ (member) == 4 then you have to use 32 bit representation to send the data, and split it over multiple values

<damo22>even if the underlying type is wider

<damo22>but kernel64/user32 needs to be taught how to read the sizes properly then?

<youpi>yes

<damo22>okay

<youpi>problem being that the kernel needs an alignment that is higher than what will be in the message

<youpi>that's an eternal problem with messages, we have the same issue with network headers etc. on archs which can't access unaligned data

<damo22>hmm do you make a copy?

<damo22>and align it for the kernel

<youpi>you may have to, yes

<youpi>possibly by luck the message is already aligned by construction

<youpi>then you can just claim it's a 64b value since it actually has the 64b alignment

<youpi>that being said on x86_64 we don't need to care

<youpi>there are also the holes questions

<youpi>possibly by luck by construction there are no holes both in 32b and 64b

<youpi>so possibly we don't need to actually implement the real translation and just need to type-cast to get the host_get_time64 etc. working

<youpi>(on x86_64 only)

<azert>may I propose a solution? revert the new style struct definitions and go back to standard mig structs (array). And deprecate any RPC that breaks in doing that

<youpi>that's to be discussed with sergio, who spent the time on fixing the struct support :)

<youpi>giving up on this just for the sake of user32/kernel64 is sad

<youpi>linux itself leans to just drop such translation actually

<azert>I understand that it is sad. But fixing it looks like even more work to do

<youpi>note that the array-based mig structures do pose the problem of alignment

<youpi>if you give an non-64b aligned array to the kernel server stub, it'll crash on 64b archs that require alignment

<youpi>so it's not a long-term solution for 64b values in rpcs

<azert>also holes, if you end up just memcpy the struct in the array

<youpi>as long as the structures don't mix types, we'll be fine, but only by luck

<youpi>but some of our structures do contain both numbers and size_t etc.

<youpi>that won't work with 64b alignment requirements

<youpi>azert: but the holes do have to match between the client and the server

<youpi>if the client and the server inherently do not have the same notion of holes, arrays won't save you

<azert>I agree with you

<youpi>and properly typing data is the only way to avoid longterm issues

<damo22>why cant we define a serialization that is agnostic to alignment?

<youpi>because it's less efficient than a memcpy?

<youpi>(when memcpy can be done)

<damo22>yeah

<damo22>ok

<damo22>but the old style structs only allow one type

<damo22>which is pretty much the only way to guarantee it will work if the first member is aligned

<azert>linux doesn't have an universal translator for 32bit to 64bit. They explicitly implement compatibility sys calls and ioctls for this issue

<youpi>which makes it very hairy yes

<youpi>notably with ioctls

<youpi>at least we fix all rpcs in one fix

<damo22>i never liked the idea of value = (*(struct thing *)data)

<damo22>its fast but has a lot of things that can go wrong

<damo22>a stream representing a data structure is not necessarily the same as the laid out memory for that data structure

<azert>MIG could integrate this code when compiling 64bit code for USER32. https://gitlab.com/qemu-project/qemu/-/raw/master/linux-user/thunk.c

<azert>thunk_convert() does exactly what we need

<azert>even better, since mig is already parsing the struct code, it could generate on the fly inTran and outTran functions in C when the ABI of the server is different from the expected client. This could result in very fast code

<azert>the fact that mig itself is written in C.. I guess is good for bootstrapping. I'd implement such a tool in python otherwise

<azert>(perl)

<youpi>that could be an approach indeed

<youpi>but we can as well just translate the message itself only when there is an alignment mismatch

<etno>Do I understand it well that waitid() can currently be used only on a child process ?

<etno>savannah gitweb is broken, let me find a source pointer to the lines I am wondering about

<etno>Well... it is hurd/proc/wait.c:220-221

<etno> if (!p->p_ochild)

<etno> return ECHILD;

<youpi>etno: only the parent can wait for a child

<etno>But something is odd, as the hurd hacking guide suggests to attach gdb to a running translator

<youpi>that's posix

<etno>Does gdb reparent the process it attaches to when it ptrace() ?

<youpi>I would be surprised it does

<youpi>trying it doesn't show a difference in ppid

<etno>ok

<etno>AIUI, gdb is calling proc_wait on the proc server. Which validated that the calling process have children in the referenced lines. Or maybe this is not what it does

<etno>Those lines did not change since befor e2000, so it would be surprising that gdb attach to a translao

<etno> ...r hasn't been working since then

<etno>There must be something happening when gdb calls ptrace(ATTACH) .

<etno>Could it be that the tracee becomes a child, but the child parent stays the same ?

IRC channel logs

2026-07-23.log