IRC channel logs
2026-02-27.log
back to list of logs
<azert>damo22: in regards of what you are saying, wouldn’t it be better to make overlapping partitions, so that the Hurd servers are initially confined to processor 1, and then smp allows the user to use all N processors including processor 1? <azert>also, since most software works on N processors, wouldn’t it be better to make software start on smp by default, and self-confine on processor 1 just the bugged components, like netdde, instead? <azert>Im also wondering if we are testing that confined tasks don’t escape their cages. Is there any way to get the cpu number from userspace? <youpi>sneek: later tell azert iirc gnumach's processor set is currently always partition, thus that choice for now <sneek>Welcome back youpi, you have 1 message! <sneek>youpi, gnucode says: what purpose does this web page serve ? https://hurdos.com/wiki/open_issues/translators_set_up_by_untrusted_users.html You make it sound like there currently is not possible to run translators set up by others, which is good. But then maybe we should delete or rename that wiki page...I'll tweak what I have and email in an update. But it sounds like it's not possible for a user to run a malicious translator <youpi>sneek: later tell azert yes, moving most of userland to cpus should be made the default, contribution welcome <nexussfan>youpi: what would the value of grub_default be set to? was reading /etc/grub.d/10_hurd, not sure <youpi>sneek: later tell gnucode no I'm not saying it's not possible to run translators set up by others. I'm saying that rm does not get tricked by it. But then it's up to tools to be careful. That's the general carefulness question, like not following symlinks blindly. <damo22>azert: yes but there are still some races that cause crash on multiprocessor, so we need to fix those first, then invert the processor sets <youpi>nexussfan: don't you already have a default value in /etc/default/grub? <youpi>you can set that to the title of the submenu you want to activate by default for instance <damo22>sneek: later tell azert yes but there are still some races that cause crash on multiprocessor, so we need to fix those first, then invert the processor sets <nexussfan>but reading /etc/grub.d/10_hurd it seems like that it just picks the first gnumach it finds <damo22>that is probably the index of the menu item, but you can also set it to the title of one iirc <sneek>azert, youpi says: iirc gnumach's processor set is currently always partition, thus that choice for now <sneek>azert, youpi says: yes, moving most of userland to cpus should be made the default, contribution welcome <sneek>azert, damo22 says: yes but there are still some races that cause crash on multiprocessor, so we need to fix those first, then invert the processor sets <azert>oh, what is the Linux api for processor sets? <azert>we should probably check old kernel versione, lets ser <azert>We should probably use NetBSD 5 code <rrq>damo22: is there a preferred way to trace smp and report on issue? (Just saying "it stopped working" doesn't give much)... is it useful with an attached gdb and post-morten tread and stack dumps ? <rrq>also, should I use a defined snapshot or is "latest unstable" good enough? <rrq>plus self-built gnumach on "latest commit" <azert>sneek: later tell youpi you are right about processor sets being only partitions and this cannot be changed without changing their meaning. What can be done is to add per-thread affinity bitmaps and manage contradictions between affinity bitmaps and processor sets at the userspace kernel interface <azert>sneek: later tell youpi specifically when you make the union between your processor set and the new affinity bitmaps, you want to avoid null results. Overall implementing per thread affinity bitmaps should be quite straightforward requiring minimal changes. This addition might impact performances <azert>for instance we have processor sets’ run idle_queues, we would now need to loop through them to find a suitable processor when scheduling, this might cost a bit <gfleury>damo22: i have played with opencode and it find the actual bug that prevent booting with smp 2 <gfleury>in i386/i386/mp_desc.c after the call of pmp_make_temporary_mapping we need to re-eanble apic with lapic_enable() <gfleury>youpi: is there any issue using IA to fix bug like that? <youpi>the question is not about the principle of the fix, but about the source code of the fix <sneek>Welcome back youpi, you have 2 messages! <sneek>youpi, azert says: you are right about processor sets being only partitions and this cannot be changed without changing their meaning. What can be done is to add per-thread affinity bitmaps and manage contradictions between affinity bitmaps and processor sets at the userspace kernel interface <sneek>youpi, azert says: specifically when you make the union between your processor set and the new affinity bitmaps, you want to avoid null results. Overall implementing per thread affinity bitmaps should be quite straightforward requiring minimal changes. This addition might impact performances <youpi>the sentence above should be enough for somebody to produce a fix and submit it <youpi>sneek: later tell azert sure, contribution welcome <gfleury>i can't find the comit which disable full smp <gnucode>is there a difference between gnumach-image-1-amd64-smp and gnumach-image-1.8-amd64-smp ? <sneek>Welcome back gnucode, you have 1 message! <sneek>gnucode, youpi says: no I'm not saying it's not possible to run translators set up by others. I'm saying that rm does not get tricked by it. But then it's up to tools to be careful. That's the general carefulness question, like not following symlinks blindly. <gfleury>i compiling rocksdb with smp 6. i getting an assertion in libdiskfs/io-read.c:64: diskfs_S_io_read: Assertion 'buf != ((void *) -1) failed' .. diskfs_finish_protid: unexpected error: cannot allocate memory <gfleury>at least i can all cpus a busy compiling