Re: [MirageOS-devel] TLS packaging status update

[Thomas Leonard <talex5@xxxxxxxxx>]

On 2 December 2014 at 20:57, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 1 Dec 2014, at 11:04, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>
>> This is taking a bit longer than expected... here's the current status.
>>
>> I have ocaml-tls working on Xen/ARM (and demoed by Anil at #osio), by
>> compiling in an OPAM switch with the right CFLAGS for Mini-OS.
>> However, we don't want to do it this way because dealing with OPAM
>> switches is annoying.
>>
>> Instead, I'm adding an ocamlfind variable which packages can use to
>> indicate the C stubs to link against under Xen. e.g. tcpip would put
>> this in its META file:
>>
>> xen_linkopts = "-ltcpip_xen_stubs"
>>
>> No libraries will be linked without this option, so we won't
>> accidentally link Unix libraries. This is important on x86_64, where
>> linking Unix libraries creates subtle race conditions due to the "red
>> zone" not being available in kernel mode.
>
> All sounds good to me!
>
>>
>> When testing this, I realised we compile openlibm for Unix, so I
>> updated that to get the CFLAGS from Mini-OS, but it turned out that
>> didn't work because Mini-OS doesn't provide sys/types.h (just
>> types.h), and also openlibm used some legacy type names that Mini-OS
>> doesn't provide. sys/types.h is currently provided by mirage-platform.
>>
>> Options:
>>
>> 1. Make openlibm depend on mirage-platform to get sys/types.h.
>> 2. Rename Mini-OS's types.h to sys/types.h and put everything there.
>> 3. Modify openlibm to use only stdint.h.
>>
>> I'm leaning towards option (3) at the moment (assuming it's possible),
>> but shout if you have a better idea!
>
> Isn't 2) a reasonable thing to do as well?  <sys/types.h> is very
> commonly included due to POSIX, so there seems little harm in making
> MiniOS's layout comply.

I did start on (2), but it's quite invasive and I'm not sure it really
belongs in Mini-OS. The mirage-platform version has legacy support for
BSD, GNU, and types like ino_t and pid_t, etc.

(3) turned out to be quite simple, and the openlibm people have merged
my patch already.

There's a PR to compile the new openlibm with Mini-OS headers here:

https://github.com/mirage/mirage-xen-minios/pull/10

>> After that, I'll update mirage-profile and tcpip to the new linking
>> system and make a pull request for the updated mirage tool. You'll
>> probably need to update several things at once when this happens.
>>
>> Then we'll be in a position to add the tls libraries. That might
>> require a little
>> extra work if we want to add Xen C stubs to 3rd-party packages (e.g.
>> zarith). Anil has suggested using OPAM depexts for this.
>>
>> Finally, we could really use some pkg-config support in OASIS.
>> Otherwise, getting the necessary CFLAGS is unreasonably difficult...
>
> Yeah.  I believe there might be some PRs floating around, but I'd
> rather put the effort into Assemblage at the moment than shoehorn
> pkg-config into OASIS at the moment...

Here's how I'm doing it currently with OASIS:

  https://github.com/mirage/mirage-tcpip/pull/85

It's a bit messy, but if it's going to be replaced with assemblage
soon then it should be OK.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel