IRC channel logs

2023-03-13.log

back to list of logs

<gighu>luckyluke: while doing some searches, I found this patch on the mailing list https://lists.gnu.org/archive/html/bug-hurd/2016-09/msg00056.html
<gighu>it seems to implement a vdso to call syscalls for gnumach
<gighu>might be worth revisit that approach, since I have the impression that it is quite flexible
<damo22>youpi1: if i iterate over all threads in a task and find the processors in each processor_set in these threads, can i just update those? but is there any harm in updating ALL cpus' ktss for iopb? since the threads might run on a different cpu soon
<luckyluke>gighu: I think such approach would be more useful to handle rpc compatiblity rather than syscall compatiblity (so a kind of vdso handled by a hurd server)
<luckyluke>it could be useful also for syscalls of course, I wonder why that patch was not merged
<youpi1>damo22: you don't want to update on a CPU if it's not a thread of the task that is running there
<youpi1>so you want to use synchronization, to make sure that threads are either running (and thus ipi needed), or not running (and thus no ipi needed)
<jpoiret>how do you usually keep track of the needed versions for each project? I tried to update everything to the latest ref, but Hurd past september needs glibc 2.37 for the new net/route.h, and the end of august refs don't work without a lot of patch backporting
<jpoiret>oh, and how do you deal with needing newer glibc in Debian btw?
<Pellescours>i think it's always keep updated in unstable