<damo22>i recovered from an old image i found <damo22>we need to get a couple of files into acpica-unix package and add to the debian rules makefile to build libacpica.a for Hurd platform <damo22>youpi: is it okay if we assume acpica will be single threaded in hurd for now? <youpi>I'm not sure what you mean exactly <damo22>it has hooks for allowing pthreads <youpi>it's fine to have single-threaded translators <youpi>when they don't need parallelism <damo22>but i want to force it to be a single threaded translator <damo22>because its easier to write the support for it, ive already done it <damo22>we are only using it to query the IRQ for a PCI device <damo22>if we need more fancy things that require parallelism, we can modify the headers and get them reaccepted <youpi>get reaccepted, what do you mean? At which time are the hooks configured? <damo22>there is acgnu.h and acgnuex.h that need to go upstream to acpica <damo22>these have hooks for things like "give me the thread id for this process" <youpi>ah, it can't be changed at runtime? <youpi>ok. I guess it's just a question of adding pthread support later? <damo22>yea, and semaphores to fix locking <youpi>that's fine for a first step <Zopolis4>I was looking into porting DDEKit to hurd, does anyone know if there is a VCS for it? (SVN, CVS, Git) <Zopolis4>I'd prefer to not have to download the tarball every time I want to check for upstream changes. <damo22>Zopolis4: i think we should focus on rump rather than dde <youpi>we're already using it for netdde <damo22>i have a branch of hurd that has acpica built in and im trying to fiddle with it to separate things we can push upstream and things we need in hurd <Zopolis4>having access to linux's range of hardware drivers would be very helpful, which is why im looking at dde <youpi>Zopolis4: yes, but dde is stuck with a very old linux layer <youpi>we *already* are using it for network drivers <youpi>there is no progress to be made there <youpi>linux is really moving way too fast for such a layer to be maintainable <youpi>thus why we're rather targetting rump, which is even integrated in bsd's development process <damo22>if you want to play with rump i can share a simple Makefile and test.c that will expose a USB device <damo22>actually just a node for a host controller <damo22>its crashing at the moment so someone needs to poke around with symbols and gdb <Zopolis4>maintaining a layer at head isint practical, i agree <youpi>Zopolis4: you are understimating the workload required to keep the linux pace <youpi>really, we have already tried <damo22>i heard there is a rump-like framework for Linux, but i forgot what its called so i couldnt even look into it <damo22>even having existing librump* working with hurd would be amazing <damo22>we have tons of unused drivers just sitting in libraries <Zopolis4>im not saying that we should try to keep up with linux <Zopolis4>i guess first order of business is to use ddekit for firmware as well before i look into making DDE/Linux3.0 or whatever <damo22>-rw-r--r-- 1 demo demo 4868066 Aug 19 19:29 libacpica.a <damo22> irq = acpi_get_irq_number(0, 31, 2); <damo22> printf("IRQ(0:1f.2) = %d\n", irq); <damo22>that should get us further with SMP ***jlledom1 is now known as jlledom
<luckyluke><damo22> "i heard there is a rump-like..." <- There was LKL but it's also unmaintained now. There was an attempt to upstream it as part of UML but required a lot of changes and I guess the original developers didn't have the resource. I was also briefly involved, but I didn't have enough time. However I still have around a packaged version of lkl for hurd, based on linux 4.19, it should be usable for filesystems and higher level drivers, but no <luckyluke>uhm, I just looked now, it seems it's still being updated, they updated to 5.10 and newer versions are in some pull request... <luckyluke>it seems they are using it to use some drivers under cygwin