IRC channel logs

<darwin>are there Debian GNU/HURD torrents?

<darwin>i'm not installing until there's something like a BSD/IllumOS, FreeSlack, Gentoo, Dragora variant, but I'd seed torrents

<darwin>well, I might install it on an old PC or in a virtual machine but can't find downloads anymore

<Gooberpatrol66>>something like a BSD/IllumOS, FreeSlack, Gentoo, Dragora variant

<Gooberpatrol66>what counts as something like those things?

<darwin>i think there was a Gentoo variant in the past. Mainly, not using apt

<Gooberpatrol66>there's a guix variant

<darwin>well that has some new initialization (init) system; what about a Devuan version?

<damo22>we need more drivers not more distros

<curiosa>luckyluke: I've seen your conversation of a few days ahead, I know that you are writing a translation layer for 32bit apps to call into the kernel using the 64bit interface, I was thinking that if I understand the mechanisms to call in the kernel right now, the right place for such a layer would not be kernel side but user side

<curiosa>the current call gate could point to a 64bit user segment, and there the translation could happen. I don't know if you are planning this right now.

<curiosa>that would result in getting rid of the 32bit trap in kernel space

<curiosa>and presenting only a 64bit SYSCALL entrypoint

<luckyluke>curiosa: that would break the current 32-bit API; it would be desirable to keep it as-is so all the changes should happen in the kernel, otherwise we need to recompile using a special 32-on-64 interface

<luckyluke>currently I'm not implementing anything yet, mainly studying the IPC code and trying to have a full overview

<luckyluke>for example, the port types are quite different from all other types

<luckyluke>they are translated form one ipc space to the other for each message, even if it's between two user tasks

<luckyluke>on the other hand, types like vm_offset-t and such need to be handled only for rpc to/from the kernel, and other direct syscalls of course

<curiosa>luckyluke why would it break the 32bit api?

<curiosa>the whole point would be to not break it at all at the ABI level, and to reuse 64bit code for msg_send

<luckyluke>it would change the syscall mechanism

<curiosa>it is currently a long call and it would stay a long call

<luckyluke>I think I don't understand what you mean then

<curiosa>I mean that instead of calling into the kernel, it could call into 64bit user code

<curiosa>that user code could be loaded by the loader

<curiosa>and do the translation

<curiosa>what is there really to translate? all the messages are typed

<luckyluke>ok, so the syscall would be served in userspace, which in turn will use some other mechanism (even the same) to enter the kernel context

<curiosa>yes

<luckyluke>you need to translate the port names, they are task-specific

<curiosa>it could use the 64bit mechanism that is still to be implemented

<luckyluke>and you can't just copy the value fro mone task to the other

<curiosa>i don't get you

<curiosa>the userspace call would happen in the same task

<curiosa>so no need to translate anything

<curiosa>kernel side, you need to upgrade to 64bit

<curiosa>but this is an orthogonal problem

<luckyluke>I think changing the syscall mechanism would just move part of the problem to userspace

<curiosa>that would be great, right?

<curiosa>since at that point gnumach would be purely a 64bit microkernel

<luckyluke>well, yes and no :) the main problem is still how to do this translation

<curiosa>maybe i am missing something, but that looks rather trivial to me. The difficult part is to finish the port of gnumach to 64bit

<luckyluke>the 64-bit part of gnumach is not fully complete yet, for example due to recent changes in mig, it now even fails to compile

<curiosa>what are you referring to? I am mendling with mig source code right now

<luckyluke>it's not yet clear how to handle some ipc types, like ports

<curiosa>go the apple way

<curiosa>ipc types are pointer kernel side and go upgraded to 64bit

<curiosa>user side you keep 32 bit

<curiosa>this is not trivial of course

<curiosa>but is not even a translation: it is just finishing porting gnumach to 64 bit

<luckyluke>mig is not the only code involved in rpc; while some types can be actually translated there, there are some implicit assumption like port size == pointer size, and messages are packet as C structs, so on 64-bit side the structure would be bigger

<luckyluke>and these assumptions are used in mach_msg()

<luckyluke>I'll have a look also at xnu, yes, but I don't know if they have a compatibility layer to run 32-bit userspace on 64-bit kernel

<curiosa>i think that it would be more useful to make a list of all places where that assumption is implicitly held

<curiosa>repacking the structure is a minor issue

<curiosa>and as I was suggesting, could be done userspace before syscalling

<curiosa>i wouldn't touch mig unless it is really buggy and do the translation at the lowest level possible

<curiosa>since changing mig would mean breaking abi compatibility

<luckyluke>I'm not sure it's even doable to do this kind of translation for all IPC, you'd need to know which data fields to change for all of them (even for IPC not involving the kernel directly)

<curiosa>it seems doable ot me, since IPC is typed

<curiosa>for IPC involving the kernel directly you would keep them the same, and add new ones if you need to get 64bit upgrades

<luckyluke>you can find which fields contain ports, yes, but what about vm_address_t?

<curiosa>I am pretty sure you can

<luckyluke>you'd need to check whether the message is directed to a user server (so don't translate it) or a kernel server (so translate it)

<curiosa>translating kernel servers wouldn't make any sense it would be impossible you are right

<curiosa>just keep them 32bit

<curiosa>and make new ones if you need

<curiosa>them to be 64bit

<curiosa>then you can slowly use the 64bit ones inside the kernel calling them from 32bit if you need to remove code duplicates

<curiosa>that's a huge

<curiosa>the thing is that even 32bit compatible kernel servers can be implemented by 64bit code

<luckyluke>sure, but the issue is still the different data representation (to say it broadly) which depends on architectural constaints (pointer size etc). I was thinking more on removing or reducing this dependency.

<curiosa>ok, just check out not to try to do anything impossible!

<curiosa>if you do not translate anything and just change the syscall interface you might obtain some good results quickly, that is also good for morale

<luckyluke>for the syscall interface, probably defining dedicate types (e.g. user_vm_address_t) would be enough

<curiosa>yep

<curiosa>vm_address_32_t maybe

<curiosa>gtg, good luck!

<luckyluke>thanks! gtg too

<youpi>damo22: do you manage to boot the hurd with rumpdisk?

<youpi>Checking root file system...fsck.ext2: malloc.c:2537: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

<youpi>I'm getting that

<gnu_srs>youpi: Yes, I know you are busy. Can you consider NMU procps, see #987557.

<gnu_srs>The problem is that the maintainer missed to remove one line when patching lib/test_process.c in procps/2:3.3.17-6.

<damo22>youpi: Hurd server bootstrap: ext2fs[part:2:device:wd0] exec startup proc auth

<youpi>gnu_srs: the patch seems to be there already?

<youpi>debian/patches/test_proc_siginfo

<youpi>damo22: that part works fine yes

<youpi>it's after that, when checking the filesystems, that the error spits out

<youpi>gnu_srs: ah now I see

<damo22>root@zamhurd:~# e2fsck /dev/wd0s3

<damo22>e2fsck 1.46.5 (30-Dec-2021)

<damo22>Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0xa0015162

<damo22>e2fsck: malloc.c:2537: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

<damo22>hmm

<damo22>could be the mapping in pci-arbiter?

<youpi>the PCI mapping are not used for mapping data

<damo22>Pellescours did make lots of changes to ext2fs

<damo22>does e2fsck get also rebuilt?

<youpi>it doesn't need to

<youpi>and there is no reason why ext2fs would behave differently between mach devices and rump devices

<damo22>i havent noticed because i turned off fsck

<youpi>did you check e.g. that fdisk works?

<youpi>possibly it's just small reads/writes that are getting bogus

<youpi>e.g. you are returning more than asked for, or such

<damo22>fdisk: libblkid/src/probe.c:687: blkid_probe_get_buffer: Assertion `bf->off <= r

<damo22>eal_off' failed.

<damo22>then ext2fs crashed

<damo22>sorry i am at work now

<youpi>damo22: perhaps in the function make sure that the returned amount of bytes read/written is exactly equal to the requested amount

<youpi>possibly rump rounds it up to a page

<youpi>and we have to truncate that

<youpi>that being said, glibc's _hurd_fd_read could be made to be defensive

<youpi>currently it'll just memcpy the amount returned by io_read

<youpi>without checking that it's smaller than the passed size

<youpi>ah no sorry it does check against it

<youpi>still better make sure that we aren't falling in such kind of trap right from rump's device_read RPC

IRC channel logs

2022-02-15.log