bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/5] acpica: Add makefile


From: Samuel Thibault
Subject: Re: [PATCH 1/5] acpica: Add makefile
Date: Wed, 31 Mar 2021 17:21:37 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Samuel Thibault, le mer. 31 mars 2021 16:49:33 +0200, a ecrit:
> Damien Zammit, le jeu. 01 avril 2021 00:23:26 +1100, a ecrit:
> > +SRCS =     \
> > +   acpi_init.c     \
> > +   dsargs.c        \
> > +   dscontrol.c     \
> > +   dsfield.c       \
> > +   dsinit.c        \
> > +   dsmethod.c      \
> > +   dsmthdat.c      \
> > +   dsobject.c      \
> > +   dsopcode.c      \
> > +   dspkginit.c     \
> > +   dsutils.c       \
> > +   dswexec.c       \
> > +   dswload.c       \
> > +   dswload2.c      \
> 
> Is it not possible to convince upstream to provide such a library
> itself? Copy/pasting the code will again pose the upstream tracking
> problem, while upstream can possibly easily define an API that can make
> it a library.

Ah, reading more how the project sees it, it seems to be meant to be
upgraded directly into the OS with gen-repo.sh etc. Then if that's
how it works already, that should be fine by us as well. I'm however
thinking that we'd probably rather make it into a separate libacpi
repository, since it won't be code that we will hold copyright on and
maintain ourself. And then possibly it actually means just simply
maintain it upstream, as I mentioned:

> Or it could be made a translator in the upstream repository, and use
> RPCs to exchange the informations we need.

not a translator, but a libacpi, that our acpi translator could simply
link against, just like our libstore links against libparted, etc.

So that was for the overal design, I'll have a closer look at the code
itself later.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]