On Wed, Aug 26, 2020 at 7:58 AM Waldek Kozaczuk <[email protected]> wrote:
> It has been almost a month and I think I can see light in the tunnel. :-) Very nice work. > > For all the files we will have to keep changing the original musl files, I > suggest we actually store the .patch files as they make it easier/quicker > to see what changes we make and automatically detect we need to update > those as we upgrade to future versions of musl. For that, we will have to > slightly change the build process. > Yes. ".patch" are not a great solution because they are hard to edit, but they are good enough for changes we just need to create once and never edit (like those stdio locking issues). In some cases it might be possible to avoid the .patch because we come up with other solutions - like that "aliases.ld" thing I did which made a lot of patches unnecessary, or macros you did for syscall(), and so on. > The main problem, I anticipate, is that there will be conflicts when we > change musl/ to the new version (1.1.24) and all of a sudden most of the > headers under include/api will be new and other ones will be old. This will > very likely affect the compilation of my C files under new musl/, libc/ and > even other ones. > It might, but then again, it might not - or - hopefully - only have small localized effects. The reason why I'm saying this is that the header files are supposed to be compatible with *standard* C and Linux, so they could not have changed too much. Sure they could have added things, but it's not like a header could define unsigned int sleep(unsigned int) and then suddenly changed to some other signature. So it is possible that you could compile the old .c files with new header files, or vice versa. I'm sure some things will break, I just hope not everything breaks. > Shall we have two include/api folders like include/api_old and > include/api (this may not work either)? Given this situation with headers, > how shall we go about executing the upgrade incrementally, ideally one > musl/src/ and libc/ subfolder at a time? Is this even possible? Any > suggestions? > I don't really know. I think at this point you have a better understanding, and more experience, at this musl-upgrade stuff than I do, so you probably have better insights on how to best do it. You can also try doing the upgrade now, and see what actually happens - what breaks and what might be the easiest way to unbreak it. > Finally, how shall we name the directories? Rename current musl/ to > musl.0.9.12/ and add musl/ subproject that would directly point to 1.1.14 > tag of the original musl git repo (git://git.musl-libc.org/musl)? I know > that right now all git subprojects point to the copies of the relevant > repos in cloudous git org. Shall we copy the 1.1.14 tag of musl somewhere > and make github subproject point to it? I have created at some point new > https://github.com/osvunikernel org where we can create the musl 1.1.14 > copy project (original musl is not on github). > > Any more suggestions regarding mechanics? Order of things to do - here is > orignal Nadav's plan (with my some adjustments): > > - Bring the latest Musl version into a "musl-1.1.24" subdirectory in > OSv (or rename musl to musl-0.9.12 and bring 1.1.24 into musl directory). > > Maybe take 1.2.1? Or are you deliberately targetting an older release? > > - Leave the old "musl/" and "libc/" directories as well. > - In Makefile, make a new list of objects (say, "nmusl") which will > take code from musl-1.1.24/ instead of musl/. > - Start to switch individual files and directories from "musl += ..." > to "nmusl += ...". We can start with the math functions needed for > aarch64. Eventually, everything can be converted to nmusl and hopefully, > nothing or little will break and need to be fixed. > - Replace our include/api with musl-1.1.24/include. Would be even > better to drop include/api, and just use musl-1.1.24/include directly if we > can. I think, though, this is low priority, and might take quite a bit of > work ("git log include/api" shows we modified this quite a bit since we > took it from musl). I'm hoping that the old header files will work > correctly also for the newer musl. > - I think this might be tricky one at this point > > > Waldek > > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/osv-dev/a49e2e1c-89fc-49b5-a87b-88b3737097e9n%40googlegroups.com > <https://groups.google.com/d/msgid/osv-dev/a49e2e1c-89fc-49b5-a87b-88b3737097e9n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CANEVyju0Q8U_tMQRDLMe0RGCj%3DsDLxJkb2Gs6-bDXHmKR3ep-A%40mail.gmail.com.
