IRC channel logs

<youpi>Pellescours: yay !

<Pellescours>It remove a lot of code :D I tested and all functionnalities are migrated correctly

<Pellescours>My point is for the config, in debian we’ll need to change the /etc/default/hurd-console file to provide config flags. The default variable names for xkbconfig are not the same as the one from x11 (XKBLAYOUT vs XKB_DEFAULT_LAYOUT)

<Pellescours>I don’t know how I should split/merge the commits before sending them. They are cannot really be applied separratly as of now.

<youpi>it's not necessarily to be split, since it'll be basically removing a lot of code and adding some code

<Pellescours>I sent a small one, it’s an simple cleaning. I’ll regroup the other ones and send them too

<damo22>nice

<damo22>youpi: how do i ensure there are no pending interrupts from outside the handler thread before telling the handler thread to shutdown?

<damo22>do i just thread_abort it

<damo22>you say that at the point where the irq_handler_remove function is called, there should be no more handled

<damo22>i dont know how to make it shutdown clean

<damo22>unless we handle one more interrupt and then shutdown

<youpi>damo22: you can't ensure there won't be some interrupts left, but that's fine, spurious interrupts & wakes are part of computer science :)

<damo22>the handler function is called when there actually is an interrupt to be handled though

<damo22>so why not handle it?

<youpi>you can leave the spurioous interrupt for next time somebody registers an interrupt, that's completely fine

<youpi>you can handle it, but not call the application handler

<damo22>ok

<youpi>since it might just not be able to be called again any more

<youpi>but again that's completely fine, the app is not driving the hardware any more

<damo22>right i see now

<damo22>so ack is ok

<damo22>but skip the handler part

<damo22>?

<youpi>that should be fine yes

<damo22>useless fact for the day: Debugging requires elevated privilege on macOS

<damo22>so will apple make it illegal to possess a debugger one day?

<azert>damo22: I think you’ll have to pay

<damo22>haha

<damo22>pay to use gdb

<azert>pay to be root, in fact

<damo22>wow

<damo22>thats insane

<azert>iOS is insane

<damo22>you already have to pay to sign applications

<damo22>so they wil run on macOS

<damo22>but the scary part is when banks make it compulsory to use a phone to do banking

<damo22>so you will need a google/apple account to transact

<azert>It’s very dystopian when a few private entities get disproportionate privileges

<damo22>yes

<damo22>how do i fight against that??

<azert>I think that taking the proverbial redpill saves people. Not sure it’s valid as a fight

<damo22>i dont know what that means

<damo22>do you mean setting a good example by not using proprietary software?

<azert>What I mean is that primarily one does that to save himself before giving a good example. Giving a good example is harder

<azert>Getting other people onboard is the way to go

<damo22>i have converted a bunch of my family over to GNU/Linux

<damo22>i only use machines that are able to run coreboot

<damo22>its still not enough

<damo22>i am forced to use some proprietary software at work

<damo22>so i have a dedicated laptop just for that

<damo22>at least the OS is GNU/Linux

<gnucode>damo22: how did you convince your family to go to GNU/Linux ?

<damo22>i started to refuse doing tech support for windows/osx and told them i am happy to help if they use GNU systems so they asked me to help them switch

<solid_black>hi all

<anatoly>heya!

<solid_black>I've got exciting news, as of yesterday evening, glibc runs on aarch64 gnumach :)

<damo22>cool

<damo22>does arm64 have more than 1 core?

<solid_black>it sure can, my phone over here has 8 for example

<damo22>so we need smp soon

<solid_black>but I haven't bothered with SMP support in aarch64 gnumach for now

<damo22>i386 smp support should be generalised so other arches can slot in

<damo22>there is model dependent code but its not all in exactly one place

<damo22>it would be sad if people implemented it as an addon in a messy way and then someone would need to rewrite it

<damo22>solid_black: does aarch64 have ACPI to detect pci routing? does it have HPET?

<damo22>i dont know how things fit together

<damo22>solid_black: we need a way to udelay() reliably on every ISA and a way to detect devices on every ISA

<damo22>on i386 that boils down to HPET for udelay() and ACPI for detecting interrupt IOAPIC/LAPIC setup

<damo22>for smp we need to know how many cores, how to enable them etc

<damo22>and interrupt settings

<solid_black>damo22: aarch64 itself is just a CPU instruction set, systms/boards based on it vary widely

<solid_black>some (higher-end) ones have ACPI yes

<solid_black>what's HPET, a timer? it does have some built-in timer, and it can have external ones

<solid_black>is udelay() just an in-kernel sleep function? what's the complication about that, why wouldn't we have that?

<solid_black>on lower-end (embedded, phones, laptops) systems, which is what we're targeting with aarch64 so far, there may not be ACPI (or maybe there is, I don't know), but there is the device tree

<solid_black>which is how we discover interrupt controllers (and everything else)

<solid_black>or at least how we're supposed to do it, we're not quite there yet :|

<solid_black>yes, the number of cores and so on can be discovered via the device tree too

<solid_black> https://docs.kernel.org/arch/arm64/arm-acpi.html

<solid_black>linux supports booting with either device tree or acpi

<solid_black>"64-bit ARM world has largely converged on two competing standards: UEFI + ACPI (largely used by servers running Windows or Linux), and the ARM64 Linux boot protocol + DeviceTree (used on smaller systems, and also supported by U-Boot and more)", from https://asahilinux.org/2021/03/progress-report-january-february-2021/

<solid_black>arm64 linux boot protocol + device tree is what I'm targeting with gnumach

<damo22>ok

<damo22>(07:07:16 PM) solid_black: is udelay() just an in-kernel sleep function? what's the complication about that, why wouldn't we have that?

<damo22>Yes, on x86 there are many ways to get a timer, but most of them are unreliable or difficult to calibrate

<damo22>that is why i chose the HPET

<damo22>its present on every x86 with ACPI since circa 2005

<damo22>sleep function, not a timer

<solid_black>aarch64 has a built-in clock in the CPU

<solid_black>on qemu virt here, it ticks at 62500000 ticks per second

<solid_black>you can ask it to generate an interrupt after a number of ticks

<damo22>ok that makes it much easier

<solid_black> https://github.com/bugaevc/gnumach/blob/wip-aarch64/aarch64/arm/timer.c

<damo22>on x86 every timer is variable

<damo22>except pit

<solid_black>wdym variable?

<damo22>every model has a different rate

<solid_black>yes, the rate is going to be different here too

<solid_black>62500000 is just the value I get on qemu virt

<damo22>but no devicetree to tell you the freq

<solid_black>ah, I see

<damo22>at least HPET has a register that tells you the rat

<damo22>e

<Pellescours>youpi: this patch https://salsa.debian.org/hurd-team/rumpkernel/-/blob/master/debian/patches/vm_pages_phys.diff?ref_type=heads is not compatible with crossbuild as it hardcode "mig" instead of using "$MIG"

<youpi>oh, right, I had copied the rule from the orig tarball

<solid_black>...setting current thread's state cannot be just thread_set_state(mach_thread_self()) after all

<solid_black>because we have to support self port interposing (for rpctrace)

<solid_black>and without a valid receive port to wait for a reply on, thread_set_state() would return when mach_thread_self() is not the real thread port, which would break things

<solid_black>so it has to be an actual syscall

<solid_black>probably doesn't have to be aarch64-specific either

<Pellescours>youpi: I have a strange behavior with console arg parser. When the last argument for KBD is --variant then the parser says "Too many non option arguments" but if I invert order and put --layout as last argument, the console start correctly

<Pellescours>actually only one order is correctly recognized

<Pellescours>nevermind, there was a typo in variable so a value was provided but empty

<damo22>youpi: how do we do spin_lock_irqsave() in a userspace driver?

<damo22>in fact, inside an interrupt handler

<youpi>you don't :)

<youpi>why do you want to?

<youpi>is it inside rumpkernel?

<youpi>or something else?

<youpi>basically the equivalent is to disable the irq (as your libirqhelp supports) and take a mutex

<youpi>(spin locks in userland are most often a no-way)

<damo22>ok

<damo22>im trying to map out what is required for hurdsound

<damo22>the ALSA internal api is not too bad

<damo22>there is a bunch of function pointers i can wrap all the drivers up into a pcm streamer

<damo22>and implement it as a jack backend

<damo22>eg intel8x0.c

<damo22>in sound/pci

IRC channel logs

2024-03-09.log