IRC channel logs

2024-02-09.log

back to list of logs

<gnucode>solid_black: If you have been looking for me, I've been on vacation. :)
<damo22>youpi: i think my last mail with the 8bit encoding setting came through again with quoted-printable:
<damo22>X-Mailer: git-send-email 2.30.2
<damo22>MIME-Version: 1.0
<damo22>Content-Transfer-Encoding: 8bit
<damo22>but in the source of the received message:
<damo22>Content-Transfer-Encoding: quoted-printable
<damo22>Content-Type: text/plain; charset=utf-8
<damo22>:(
<damo22>ive sent a support request to proton to have the emails fixed
<damo22>i think my mail bridge is doctoring the content
<damo22>youpi: can you confirm this email still has the wrong encoding? https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00049.html
<etno>damo22: I have "Content-Transfer-Encoding: quoted-printable" here, for this one
<damo22>:(
<damo22>i set it to 8bit on my end but it got changed before it reached the list
<etno>Arhhh... I tend to agree with solid_black that the transport encoding should not make a difference in the final message content. But it is frustrating that intermediate services mangle your messages
<damo22>it depends what you mean by final message content. mbox format is plain off the wire, as far as i know, and some mail clients parse other formats
<damo22>but my email was created using a plain text editor, why cant it just send it as is?
<damo22>i hate things mangling my messages
<damo22> // Use quoted-printable for all text/... parts
<damo22> hdr.Set("Content-Transfer-Encoding", "quoted-printable")
<damo22>ugh
<damo22>heh https://github.com/ProtonMail/proton-bridge/issues/461
<damo22> Hurd server bootstrap: ext2fs[part:2:device:wd0] exec startup proc auth.
<damo22>
<damo22> INIT: No inittab.d directory found
<damo22>with smp -2
<damo22>-smp 3
<damo22>2*
<damo22>youpi: can i create a processor_set with just BSP in it and then assign essential tasks to be that set?
<damo22>do psets have to partition the space of processors?
<damo22>or can they overlap
<youpi>I don't know
<solid_black>a processor belongs to exactly one pset
<solid_black>you, as in the kernel, only need to assign new processors to the default processor set
<damo22>solid_black: i want to move BSP to its own pset
<damo22>for testing
<solid_black>it's the userland that can call processor_set_create() + processor_assign() to make more psets and move processors between them
<solid_black>why?
<damo22>so i can easily isolate essential tasks to only run on BSP
<damo22>in case there is some races in bootup
<damo22>and the rest might just work
<youpi>the rest is software that runs fine on linux-smp, so it will just work indeed :)
<damo22>it wouldnt even hurt to keep it that way until we fix it
<youpi>yes
<damo22>if it means we can have smp enabled
<youpi>yes, so at least gcc etc. get parallelized
<damo22>:D
<solid_black>as a temporary measure, sure, it makes sense
<damo22>i am looking forward to running -smp 7
<youpi>7 ? why not 8 ?
<damo22>because my last cpu is for host
<youpi>does the host eat that much cpu time?
<damo22>no but i dont want to choke the host if i exhaust with testing hurd
<solid_black>you should be able to configure your host in a way that lets the host use the CPU whenever it needs it, but yield it to the guest otherwise
<solid_black>so that the guest can not preempt the host, but can still use it when the host is idle
<youpi>you can nice the kvm process
<solid_black>i.e. run the guest with lower priority
<damo22>ok
<youpi>then you're sure it can't hose
<solid_black>I'd expect just "nice qemu" to do the trick
<damo22>-smp 8 then
<solid_black>the pset interface could/should be used for things like performance/effeciency cores split
<damo22>my sound card has not dropped a frame for a month
<damo22>:D
<solid_black>though I wonder what kind of a mechanism we'd need in the Hurd to manage that
<damo22>12ms latency
<damo22>*pset = processor->processor_set;
<damo22>i think youre right, the get_assignment means it only belongs to one set
<youpi>doesn't the documentation talk about it?
<solid_black>hasn't the ipc_entry_lookup_failed Wincompatible-pointer-types error been fixed?
<solid_black>hm, no, I have not posted the patch
<damo22>i cant find much about processor sets in web.git
<damo22><!-- This is called SMP; the processors use *shared memory*. --> [[!tag open_issue_documentation]] <!-- This needs a new page, also covering Mach's `processor_set`s, and non-SMP, but still multiprocessor systems. -->
<youpi>I mean the mach documentation
<youpi>info mach
<youpi>built from mach.texi
<solid_black> https://www.gnu.org/software/hurd/gnumach-doc/Processors-and-Processor-Sets.html
<damo22> The function 'processor_assign' assigns PROCESSOR to the set
<damo22> PROCESSOR_SET. After the assignment is completed, the processor
<damo22> only executes threads that are assigned to that processor set. Any
<damo22> previous assignment of the processor is nullified. The master
<damo22> processor cannot be reassigned.
<damo22>looks like isolated venn diagram
<solid_black>it is, yes
<damo22>that is news to me
<solid_black>do I understand it right that the spl* thing is just turning interrupts on and off?
<solid_black>as in, *all* of interrupts, without any actual levels?
<damo22>yes, it keeps the flags and restores them back the way they were
<damo22>but after the call, its "cli" in the middle
<solid_black>so could we potentially drop all of the spl* cruft and just have disable_interrupts() / enable_interrupts() ?
<youpi>it's already essentially dropped
<youpi>you can rename spl to disable_interrupts, but that'll basically be the same
<damo22>we could, but it could be useful to keep the original names
<solid_black>I see, thanks
<damo22>solid_black: but note that its not equivalent to asm("cli")
<solid_black>in that it also keeps track of the level in some globals? or how?
<damo22>because it also restores the previous state after the splx(s)
<solid_black>ACTION is used to sti() and cli() from kSerenityOS
<damo22>so nesting them works
<youpi>that's what disable/enable_interrupts() macro usually do too, yes
<solid_black>right, so splx() is exchanging the given level and returning the previous one?
<youpi>yes
<youpi>solid_black: does cli() not return the previous state ?
<solid_black>in SerenityOS, no
<youpi>in kSerenityOS ?
<youpi>that looks bogus to me
<youpi>all OSes I have seen have met the need to
<solid_black>the InterruptDisabler class does though
<youpi>honestly I'm depressed to see how much the newer OSes don't seem to actually take care of looking at the past efforts, to avoid making exactly the same mistakes as their elders
<youpi>there is so much experience which is just lost
<solid_black>given how far ahead SerenityOS is, we'd better start copying their mistakes :)
<damo22>i wont be
<damo22>i get most of my knowledge from datasheets and previous os/firmware source
<solid_black>the InterruptDisabler class is a RAII guard
<solid_black>it re-enables interrupts when you exit the block, if they were created when you were entering it
<damo22>i cant write an OS in C++
<youpi>solid_black: ok, but I mean, the very fact that you got used to cli()/sti() means that it's used significantly
<youpi>while an OS should really *not* be used to do that
<youpi>that's just the lesson learnt over the early development of linux for instance
<youpi>almost no code in linux does cli()/sti()
<youpi>(note: there is no need for c++ to get RAII support, the __cleanup__ attribute can be used for that)
<solid_black>yes, but I don't think we actually want to use it?
<youpi>why not?
<solid_black>I've seen the systemd codebase, and glib/GNOME people use it
<solid_black>but not any (non-GNOME) GNU projects
<youpi>glibc does use it for instance
<solid_black>even if they rely on other GCC-only specifics
<solid_black>it does?
<solid_black>wher?
<youpi>in pthread_cleanup_push
<youpi> https://codesearch.debian.net/search?q=__cleanup__&hl=en
<solid_black>does attribute((cleanup)) interact with unwinding / pthread cancellation?
<solid_black>not that it's important for the kernel context
<youpi>with -fexceptions it does
<solid_black>so, are you suggesting we drop spl* APIs and have a InterruptDisabler-like API based on attribute((cleanup))?
<youpi>I'm just saying that one doesn't need C++ to get this
<youpi>whether it's the most pressing priority to replace the spl api with something raii, I don't think it is
<solid_black>certainly not the most pressing :)
<solid_black>I'm just trying to build Luca's aarch64 branch, and having erros related to spl*
<youpi>errors?
<solid_black>not enough things are defined/stubbed, apparently
<saravia>Hi some could tell how run hurd <-- for example the peculiarity of use 100% of processor <-- is for what? which does a operative system with that characterics
<azeem>can you rephrase the question?
<etno>My Dell laptop successfully booted using rumpdisk instead of the gnumach driver 👍
<etno>The ACPI server takes 1mn to start, though. Is this something you have already experienced?
<gnucode>howdy friends
<nikolar>Howdy
<gnucode>heyo nikolar
<nikolar>What's up
<gnucode>Not a lot. Missing my OpenBSD install on my laptop. I think I managed to fry the drive somehow.
<azert>etno: cool. What processor is your dell laptop?
<azert>Processor sets are interesting, I once played with that api. I thought that the Linux affinity bitmap is more powerful
<azert>But one could make a tool similar to tasksel for Hurd to expose the processor set api to root users
<azert>I think it’s a straightforward thing to do.
<azert>Apparently netbsd has a compatible api to gnumach
<azert> https://man.netbsd.org/psrset.8 could be ported to the hurd
<anatoly>they're wondering why hurd consumes 100% of CPU and what can be done to prevent it
<azert>How comes? It doesn’t use that much cpu in my vm
<anatoly>that was about saravia questions
<anatoly>Sorry I didn't scroll down enough :-)
<azert>Is there any interest to port this https://github.com/NetBSD/src/blob/trunk/usr.sbin/psrset/psrset.c to the Hurd?
<azert>I might do it in my free time if it is useful
<gnucode>azert: that could be a question for damien
<azert>Yes
<nikolar>gnucode: how did you fry your drive
<gnucode>I'm pretty sure I was holding my drive whilst wearing socks on carpet....