IRC channel logs


back to list of logs

<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.
<youpi>DDEkit is mostly dead
<damo22>Zopolis4: i think we should focus on rump rather than dde
<youpi>we're already using it for netdde
<youpi>but it's quite stuck
<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
<youpi>great :)
<damo22>i just rebased it on master
<damo22>the first commit will go away
<damo22>because it will link to .a
<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
<Zopolis4>but like
<Zopolis4>going from 2.6 to 3.x
<Zopolis4>and so on
<damo22>why not start with 5.0
<Zopolis4>incremental changes are easier
<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(0:1f.2) = 10
<damo22> acpi_init();
<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
<damo22>and APIC
***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