IRC channel logs


back to list of 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 $@
<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 or the 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
<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
<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
<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>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>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)
<janneke>there's no hurry, it's just an interesting thought
<damo22>smp is working but its sloooow
<damo22>locking is weird
<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
<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)?