IRC channel logs


back to list of logs

<damo22>this library works
<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>and has no way to build the lib
<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>we need this version
<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
<youpi>why couldn't it be?
<damo22>because we are the only user of it, and it would be almost a complete rewrite
<youpi>I don't understand
<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?
<damo22>debian package
<youpi>the debian package is orphaned
<youpi>nobody cares at the moment
<youpi>so it's really not a problem to revamp it
<youpi>we can just adopt it
<damo22>can you take a quick look at what ive done its literally 2 makefiles and a bit of glue
<damo22>but it works
<youpi>you mean the Makefile, acgnu.h, acgnuex.h and gloal_state.c files?
<damo22>the toplevel makefile
<youpi>they look simple enough, and more importantly, that looks like something upstreamable
<youpi>so it's maintained there
<youpi>rather than having to follow yet another project to update it
<damo22>so which project should this be upstreamed to?
<damo22>the debian packge?
<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>damo22: I don't know
<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
<damo22>thats why is needed
<youpi>different from what?
<damo22>different to what we need
<youpi>really, I know next to nothing about how all that is structured
<damo22>its in subfolders etc
<damo22>and the code is written differentl
<youpi>which script ?
<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>then it's not a problem
<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>s/works/used/ then?
<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 tool, patches their source and then compiles a library
<youpi>why patching?
<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?
<damo22>lol really? i didnt know
<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>i see
<damo22>we dont really need the tools
<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?
<damo22>acpica is BSD-3 / GPLv2-only
<youpi>(avoid some of it)
<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>we don't have to choose
<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>ah, rumpdisk needs it
<damo22>it will when APIC comes online
<youpi>then a static version is needed indeed, but we might have licensing problems
<youpi>possibly we'd have to introduce an acpi translator
<damo22>i have already written it
<youpi>to separate out licenses
<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?
<damo22>and provide the NOTICE
<youpi>though I'd rather recommend making the acpi translator gplv2+
<youpi>to avoid getting stuck at some point
<damo22>thats why i wrote this:
<damo22>hmm acpi translator cannot be a netfs if there is no filesystem at boot
<youpi>? I believe it can
<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>in that case yes
<youpi>I've just pushed a note
<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>e.g. to bulld a statically-linked binary
<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?
<luckyluke>32 bit userspace on 64 bit kernel