IRC channel logs

<gabber>what would the riscv64 subsystem number be? do i just choose one that is not listed in hurd/hurd/subsystems?

<gabber>and does anybody here have good recommenation to dive deeper into MIG/Matchmaker? i've been reading up on whatever i could find but i haven't found a language description or reference or something like that (i might not be too good in web-search, please forgive me)

<youpi1>gabber: a subsystem, but what for?

<youpi1>I guess riscv uses a normal register for thread register

<youpi1>and I guess it doesn't have I/O instructions

<youpi1>so I don't see any equivalent of the mach_i386.defs primitives needed for riscv

<gabber>ah, i see :) yes i was referring to that. i'm still skimming i386 sources trying to get an overview (with the riscv privileged reference in the back of my head somewhere).

<gabber>by "thread register" you mean like a thread local stack pointer?

<damo22>how do you rename .o files inline so that file.c compiles to file.suffix.o

<damo22>my makefile foo is not very good

<DiffieHellman>With mv maybe?

<damo22>my problem is with makemode := servers

<damo22>i cant seem to compile the object files to a different name

<damo22>so they end up the same and linked to the previous one

<damo22>the files are slightly different because they have ifdefs in them with a -D_PARAM to separate the two cases

<damo22>but they have the same name

<damo22>i need a makefile target that compiles a .c file -> .suffix.o

<gabber>i guess the target would be something like `%.suffix.o: %.c` while the rules remain something like `$(CC) $(CFLAGS) -c %< -o $@` (haven't tested this though)

<gabber>you'd need a a dependency for `%.suffix.o` then, though

<damo22>%.disk.o: %.c

<damo22> $(CC) $(CFLAGS) -c $< -o $@

<damo22>yeah

<gabber>does it work?

<damo22>i need to figure out the rest of the flags im missing

<damo22>i shouldnt need to mess with the makefile so low level though

<gabber>this is usually done in configure.ac or the Makefile.in templates (which generate the actual Makefile)

<damo22>not in hurd

<gabber>true. so WDYM "i shouldnt need to mess with the makefile so low level"? it's the only way to get make to do what you need, no?

<damo22>yeah thanks

<gabber>YW

<damo22>DIOCGMEDIASIZE ioctl fails

<damo22>ext2fs: part:2:device:wd0: No such device or address

<damo22>wow never seen that

<damo22>got it

<damo22>mailed in patch for usb

<DiffieHellman>Nice.

<AlmuHS>damo22: i saw this error in AHCI too, in some laptops

<AlmuHS>i think that I saw it in CDROM

<damo22>janneke: rumpkernel is now taking "473.4 MB Project Storage" in salsa, i think someone needs to run git gc

<damo22>force push must have just added the extra history

<janneke>damo22: yes, i saw that

<janneke>luckily, when (guix does a) git clone, only 137 MB is downloaded

<damo22>yes

<janneke>i suppose that the gitlab instance has a cron job for that

<janneke>ACTION would hope so, at least

<damo22>i did a fresh clone

<damo22>it was nice

<janneke>ACTION is very happy with this co-creation ;-)

<damo22>:D

<damo22>i just mailed in usb support

<damo22>my qemu booted off a xhci usb mass storage emulated device

<janneke>yes, i love to see the progress you are all making

<janneke>writing patches, sensible review comments, etc

<damo22>i wish more people would contribute

<damo22>development is slow

<janneke>being so close to running it on hardware is very tempting, i guess

<damo22>yes

<damo22>i need to figure out this irq sharing bug

<janneke>i'm wonder what will happen when "we" get hurd to run on something interesting (64bit smp)

<damo22>hehe

<janneke>there's no hurry, it's just an interesting thought

<damo22>smp is working but its sloooow

<damo22>locking is weird

<janneke>ouch

<damo22>i dont know how to fix the locking in gnumach

<damo22>i guess next step is to find the most contended locks

<damo22>i have a printout of addresses

<damo22>finding the function located at address X is not easy

<damo22>at runtime

<janneke>ah, right

<janneke>well, i guess disk, usb, and net are also pretty interesting

<janneke>(possibly even more so)

<damo22>these should be solvable easily

<damo22>more so than fixing smp / 64 bit / acpi

<damo22>usb disk support was about 80 LOC

<damo22>sharing the existing code

<janneke>yes, pretty amazing

<damo22>rump is a giant beast

<damo22>i wish i could split the usb stack into host/device

<damo22>then we could have dev nodes for the usb controllers and use hurdish translators to connect the device drivers to the device nodes

<damo22>otherwise the usb mass storage disk driver has the entire usb stack built into it

<janneke>ah

<damo22>RUMP_MEMLIMIT=40m does not seem to limit rump's memory

<damo22>it seems to be allocating as much as possible until it fails, and then flushes some pages to reclaim

<spk121>Theoretically, how hard would it be to make hurd do SATA and a console via UART or USB? There are couple Intel-based SBCs lying around here I could try.

<luckyluke>spk121: the console driver is still in the kernel, and IIRC it should already support the i386 serial ports (at least on qemu) with the console=com0 or com1 parameter

<gabber>what is Mach's entry point? what is in .boot (the first section in the ldscript)?

IRC channel logs

2023-06-28.log