IRC channel logs
2022-08-20.log
back to list of logs
<damo22>youpi: acpica-unix package is too convoluted to add libacpica.a, so i rolled my own library that can refresh source from upstream on any version we want <damo22>my library generates libacpica.a and the required headers for /usr/include/acpi <youpi>"your own", what do you mean, how is it different? <damo22>the debian package for acpica-unix does not use the linuxized version of the acpica code <damo22>they are using the upstream makefiles <damo22>to simply build the tools that come with acpica <youpi>I mean, can't that be upstreamed? <youpi>in the past decades we've always seen "we can refresh easily" fail <damo22>upstream provides and maintains a tool to generate the linux headers/code that is pulled into Linux <damo22>so that we can simply do #include <acpi/acpi.h> <damo22>and everything works on our ende <damo22>the acpica-unix package is a bunch of binaries that do various operations on acpi <damo22>its not there to provide a userspace library or header files <damo22>because we are the only user of it, and it would be almost a complete rewrite <youpi>you're saying your version can easily adapt to newer source <youpi>and you're saying at the same time that it'd be a complete rewrite <youpi>also, being the only user is not really a problem if it's not burdensome to maintain it <damo22>no their existing package would need to be rewritten <youpi>and also, with all the library-based OS nowadays (UniKernel etc.) it's a tendency that can stick <youpi>package = upstream package or debian package? <youpi>the debian package is orphaned <youpi>so it's really not a problem to revamp it <youpi>you mean the Makefile, acgnu.h, acgnuex.h and gloal_state.c files? <youpi>they look simple enough, and more importantly, that looks like something upstreamable <youpi>rather than having to follow yet another project to update it <damo22>so which project should this be upstreamed to? <youpi>about pci-arbiter / rumpdisk / ext2fs not showing up in ps, I have found why: _hurd_libc_proc_init was not actually getting called <youpi>for some reason configure was not finding the function <youpi>but.... now that it finds it with glibc 2.34, things go mayhem when running fakeroot <youpi>so I had to disable it again <youpi>I don't know how acpica is structured <youpi>where the debian source is coming from <youpi>but I believe that the acpica project can be interesting in integrating a small makefile to make it provide a proper library <damo22>problem is, the acpica project maintains its source in a different format and layout <youpi>really, I know next to nothing about how all that is structured <damo22>and the code is written differentl <damo22>there is a conversion script written in C that parses the acpica code and rewrites it to look like linux code <youpi>is it maintained by acpica ? <youpi>really, the *only* concern in all these kind of glue layers, is to maintain ourself as little as possible <youpi>and what we possibly maintain, we keep in the upstream repo <youpi>so that maintainers of the upstream repo have a chance to remember to update it <youpi>it doesn't mean that it always happens (see the pciutils fix I've just made because lspci was completely broken) <youpi>but the chances are much higher, and in practice it does work fine enough <damo22>everything we need is in acpica itself except for acgnu.h and acgnuex.h, but we need some makefile foo added to the debian package then <youpi>can'(t we push acgnu.h and acgnuex.h to upstream acpi? <damo22>yes if we're happy enough with it <youpi>can't the makefile be pushed there too? <youpi>so that it's maintained or even CI-ed there <damo22>er, it only works on hurd as far as i know <youpi>why would it only work on the hurd? <damo22>because we are using it in userspace <youpi>again, library-based OSes are a trend nowadays <youpi>so pushing in that direction will be welcome, I believe <youpi>maintaining the makefile in upstream won't be really harder than maintaining in our corner <youpi>and the *real* benefit is that it exposes it so that exokernel-like people can notice it and take part in the party <damo22>theres a tonne of patches in the debian package for big endian machines <youpi>they we never upstreamed? ew <youpi>I guess upstream would be interested in them <youpi>even if possibly more endianness issues have slipped in in the meanwhile <youpi> * Big-endian (aka s390x) support has been completely revamped; if <youpi> upstream accepts the new version, this can go away; the result is <youpi> that all of the older big-endian patches have been replaced. <youpi>so in theory possibly they are not useful any more <youpi>they don't seem to appear in the upstream git repo <youpi>they seem to still apply mostly well <damo22>i dont think acpica will accept a makefile that runs their gen-repo.sh tool, patches their source and then compiles a library <damo22>there are 2 lines i had to change plus a sed script i had to replace "struct struct", i dont know whats wrong but it could be a bug <youpi>probably the bug can just be fixeD? <youpi>you mean the actypes.patch ? <youpi>it seems to be already fixed upstream, isn't it? <youpi>so it seems that just nobody took the time to follow on <youpi>do we actually need the tools provided by acpica-unix? <youpi>we can as well just leave it up to people who actually want them on big-endian machines (those people are possibly *paid* to do the work) <youpi>and introduce another package to build libacpica <youpi>my point is just that we shouldb e able to have to maintain only the debian package, and not the upstreamable makefile <damo22>we just want a libacpica.a and headers <damo22>i think it would be useful to have it as a separate package so we dont introduce breakage when someone updates it for a different arch <youpi>.so rather, to avoid licensing concerns? <youpi>yes, sure, but you never konw <damo22>maybe we should take the BSD versoin <damo22>so we can still have a gplv3 superset <youpi>the debian package can provide the different licenses <damo22>i mean, it will link at the object level to a hurd translator <youpi>yes, but with a .so e.g. LGPL is fine with that <youpi>while with a .a it's not because you cannot replace the library <damo22>we need a statically linked binary, to bootstrap rumpdisk <youpi>then a static version is needed indeed, but we might have licensing problems <youpi>possibly we'd have to introduce an acpi translator <youpi>so you mean the .a for the acpi translator? <youpi>we can easily keep the acpi translator whatever license needed to have acpica <damo22>yea but if libacpica.a is BSD-3 can we just link it to a gplv3 acpi translator? <youpi>though I'd rather recommend making the acpi translator gplv2+ <youpi>to avoid getting stuck at some point <damo22>hmm acpi translator cannot be a netfs if there is no filesystem at boot <youpi>it's just unattached at first <damo22>its the chicken egg problem we saw before right? <youpi>it can provide a device on which it serves its filesystem <damo22>does it need to be a libmachdev as well? <youpi>apparently the only concern we had in the pci-arbiter case was that libmachdev would only run libtrivfs, and not libnetfs, on the translated path <youpi>I don't think it's unfixable <youpi>possibly by letting pci-arbiter provide a piece of demuxer to run the netfs demuxer before/after the libmachdev demuxer <damo22>i also wrote a test program that implements the missing hooks from libacpica.a and calls the irq lookup function, it all compiles and links using my library <damo22>once we have a debian package for the lib, it will be almost trivial to put the missing code into hurd and look up IRQs <Pellescours>luckyluke: I want to test your patches for x86_64, can I only build MIG or should I also build hurd (and some others?) because of the types changes? <Pellescours>damo22: can you send me the Makefile and test.c for USB? I want to play with it <luckyluke>Pellescours: only mig, to build a 64 bit gnumach <luckyluke>You should be able to use the debian binaries for hurd, I'm using these for testing <luckyluke>Although there is still some bug, booting from ramdisk I could start proc and auth, but not bash (yet) <luckyluke>Btw, the patched mig should be usable also to build user-space stuff, I have some "unit tests" for that <luckyluke>The issue with mig is that you need a 32/64 bit version depending on what you want to compile <Pellescours>you mean having 2 mig? one for 64 bits and 1 for 32 bit <youpi>luckyluke, Pellescours: it's not a problem building mig two times for two different targets <youpi>that's what host/build/target triplets are for :) <luckyluke>Sure, but it wouldn't be difficult to have a -m32 flag as in gcc, if needed <luckyluke>Another mig variant would be probably needed for 64-bit userspace, because of the vm types. I'm not sure the triplets could handle this case for kernel compilation <Pellescours>but luckyluke, you said that you where able to boot with ramdisk, but is it working in a pure 32 bit?