WEBVTT 00:00.000 --> 00:10.920 In the 111 team, particularly on the embedded side, my specialty is in linkers, modern sea 00:10.920 --> 00:11.920 libraries. 00:11.920 --> 00:15.800 But one of the things that we'd like to do with the embedded tool chain is have a wider 00:15.800 --> 00:17.400 adoption of L.O.V.M. 00:17.400 --> 00:24.200 And so this is where this talk is kind of like a mixture of an overview of what L.O.V.M. 00:24.200 --> 00:26.440 L.O.V.M. 00:26.440 --> 00:27.720 L.O.V.M. 00:27.720 --> 00:28.720 How would you? 00:28.720 --> 00:32.080 How would you contribute to it? 00:32.080 --> 00:34.160 So yeah, what we're going to look at. 00:34.160 --> 00:36.640 Yeah, basically what is L.O.V.M. 00:36.640 --> 00:41.440 generally, just in case anyone is unaware that a lib C is more than just a C library, I guess 00:41.440 --> 00:46.160 at that particular point, whereabouts is it, how to build it, and then a little bit about how 00:46.160 --> 00:53.440 it's different time embedded systems and how to get involved. So yeah, so this slide is just 00:53.440 --> 00:57.280 sort of showing you generally, if you think of just the C standard library, you've got your 00:57.280 --> 01:01.840 standard functions, so I don't know, like Memcopy, PrintF, that type of thing, but it's a little 01:01.920 --> 01:07.040 bit more than that, particularly if you take say something like G-Lib C on Linux, you find 01:07.040 --> 01:12.480 that it also includes a lot of posics functions, you might have it things like creating threads, 01:12.480 --> 01:17.200 that type of thing, you may also have the runtime library, where it's like setting up the heap, 01:17.200 --> 01:21.680 that type of thing, where all of these sort of things are just slightly more, well, 01:21.680 --> 01:26.560 I look in some cases for a big operating system, quite a bit larger than the C standard library, 01:27.520 --> 01:32.640 so yeah, and the boundaries between these various components will, it's all a little bit fuzzy, 01:32.640 --> 01:37.280 you know, some libraries will decide to add more things in the sort of more C library side, 01:37.280 --> 01:42.000 some of them have a richer platform interface, some of them have a very narrow one, that type of thing, 01:42.000 --> 01:47.840 but the main, main message here is that C library is more than just a standard C functions, 01:47.840 --> 01:53.520 and different platforms will do things in different ways. So here's a sort of a sort of 01:53.520 --> 01:57.120 block diagram of how you might want to do things in Linux, now if you're, if you're say 01:58.400 --> 02:02.880 on an operating system like Linux, you want to implement my lock, you can ask the operating 02:02.880 --> 02:07.120 system for some memory, in fact you probably must ask the operating system from memory, because if you 02:07.120 --> 02:11.840 do it in the other way, it'll probably probably cook them at your program, and you've also got 02:11.840 --> 02:18.240 the interface to the kernel, I think Linux's got a stable kernel interface, so you can actually 02:18.240 --> 02:23.120 call directly without using the C library, but some operating systems, that's not the case, 02:23.120 --> 02:28.880 and if you do one thing on the kernel with one release, and then you change to the next one, 02:28.880 --> 02:32.720 you'll suddenly find your system call doesn't work, so in those cases to simply see the 02:32.720 --> 02:38.000 ellipsy is the only way you can stable interface at that particular point. On an embedded system, 02:38.000 --> 02:44.400 this might be a bit different. In this case, you're operating in free standing mode where 02:44.400 --> 02:49.120 you're kind of, you don't necessarily, or you can't make any assumption about what operating 02:49.120 --> 02:53.920 system you're running on, if there is an operating system at all, and in that case, 02:53.920 --> 02:58.320 the C library will generally provide you with a porting layer that the operating system then 02:58.320 --> 03:04.480 implements that type of thing, so generally speaking here, difference between the two 03:04.480 --> 03:08.400 two sort of forms is one, you have to implement in terms of what the kernel does, the other one, 03:08.400 --> 03:15.040 the kernel kind of has to adapt to what you do in an actual point. Okay, so the reason I went through 03:15.040 --> 03:20.800 those sort of differences is that what does ellipsy mean in L of M, because it's not like it's 03:20.800 --> 03:28.000 the platform compiler for any one particular tool chain. I mean, it is for say, or some platforms 03:28.000 --> 03:35.040 have chosen L of M as their platform compiler, but that's not all it is. So what the L of M 03:35.040 --> 03:40.640 ellipsy sort of that wanted to do was to have something that was customisable for the 03:40.640 --> 03:46.960 particularly use case. So you can sort of scale things up or scale things down. If your platform 03:46.960 --> 03:51.280 doesn't support certain things, then you should be able to exclude them. If you're on an embedded 03:51.280 --> 03:57.680 system, you may not choose giant lookup tables for your library functions, but you may choose to do 03:57.680 --> 04:03.440 that if you're running on an operating system, that type of thing. It also permits some non-standard 04:03.440 --> 04:08.160 targets, I guess, when I say non-standard isn't, I mean not a CPU, I guess I'd have a particular point. 04:09.120 --> 04:17.360 A particular L of M focus is sort of I guess using the static binaries that come out of it. So this 04:17.360 --> 04:22.320 would be a sort of full static linking without any license implications, or at least the L of 04:22.320 --> 04:29.920 M license implications, as opposed to say anything GPL or MIT, which might require you, or it might 04:29.920 --> 04:36.000 require a program using ellipsy to disclose what licenses it's using, that type of thing. I think 04:36.000 --> 04:43.280 one of the main motivations for the people who started the project was basically similar up, 04:43.280 --> 04:48.800 similar results, or identical results, particularly for the math library functions on different platforms. 04:48.800 --> 04:54.640 So if you can imagine if you've got a program and you might dispatch it to say one of three different 04:54.640 --> 04:59.360 architectures in a cloud, and it's got different implementations of the math library, and it gives you 04:59.360 --> 05:04.080 different results, then that's probably not going to be acceptable to you. So you're going to have to 05:04.080 --> 05:10.160 want at least one standard implementation, and L of M lib C is chosen to go down the route of 05:10.160 --> 05:14.880 correctly rounded, math library functions, as far as I'm aware, I'm not an expert in this. 05:15.440 --> 05:20.800 I triple E75 for mandates that you correctly round your operations, but it doesn't 05:21.360 --> 05:26.640 require that you correctly round your math library functions, that type of thing, because it's 05:26.640 --> 05:31.120 considerably harder to do, but there's been a lot of research in that area, so L of M lib C's 05:31.200 --> 05:40.000 been able to adopt that. And finally, there's a lot of opportunities for, I guess, the horrible 05:40.000 --> 05:44.880 synergy word between different components, like for example, you might be able to share code 05:44.880 --> 05:50.480 between lib C++ and L of M lib C, that type of thing, and one of the things that's particularly 05:50.480 --> 05:57.280 attractive for us at arm, who we make in L of M embedded tool chain, is we can build a whole tool chain 05:57.360 --> 06:02.240 from just one project and not have to mix and match between different open source projects, 06:02.240 --> 06:06.560 and the various sort of impedance mismatches you get when one of the projects changes without 06:06.560 --> 06:12.800 the other one knowing about it. Okay, so there are some challenges to do this. This was sort of 06:12.800 --> 06:20.800 amply pointed out on the thread when L of M lib C was put forward. It's an L of M lib C is far more 06:20.800 --> 06:26.880 platform dependent than it is compiler dependent, so does it really deserve to live in L of M lib C? 06:27.600 --> 06:31.520 I guess you could say that the people who started the project think, it's worth a go. 06:31.520 --> 06:36.080 Let's see where we get to. We know it's going to be challenging, but let's just take that 06:36.080 --> 06:42.000 challenge on board, I guess, at that particular point. Yeah, so I think the other thing I guess is 06:42.000 --> 06:46.800 that, well, as lib C's already, why do we need another one? I guess part of that answer is why 06:46.800 --> 06:51.840 there's so many build systems, I guess at some point, at least at some point, the people who 06:51.840 --> 06:57.200 wanted to start L of M lib C thought that there was space for yet another C library, 06:57.200 --> 07:03.040 that took to be implemented. Okay, so moving it on to where are we at today? So, 07:03.040 --> 07:07.440 this started, I think, probably about five years ago, so there's been about five years of 07:07.440 --> 07:14.960 development since that one's going there. So, first intervention from L of M lib C's, you can build 07:14.960 --> 07:20.320 it in two configurations. The one, if you just want to try it out quickly and you're already 07:20.320 --> 07:27.040 on Linux, then building it in overlay mode is the easiest thing and that's kind of using it to 07:27.040 --> 07:32.080 supplement an existing C library and I'll go into that use case a little bit more detail later. 07:32.080 --> 07:36.240 And then there's a four build, which says, I'm going to be the only lib C on the system at that 07:36.240 --> 07:40.480 two point. And obviously, if you're doing an embedded system, you have to do it in the four board 07:40.480 --> 07:48.720 way. Supports a number of architectures, I guess you could say, the major ones you would expect. 07:48.720 --> 07:52.960 I guess at that point, the interesting ones are the GPUs, which is probably not what you would 07:52.960 --> 07:58.240 expect, but there's been a lot of really, really interesting work done on the GPUs of late. 07:58.240 --> 08:02.560 I won't go into that in too much detail. But if you are interested, there's some really good 08:02.560 --> 08:08.000 presentations at the L of M dev meeting by Joseph Hugo. So, I do recommend tracking those down on 08:08.000 --> 08:11.920 YouTube and watching those. He does a very good job of going through how those work. 08:13.920 --> 08:18.160 And again, mentioning that Linux is probably the primary Linux and embedded, 08:19.040 --> 08:22.640 probably the most primarily supported out of the traditional targets. 08:23.520 --> 08:30.800 I think there will plans for Darwin, Mac OS, type thing, and Windows. But I think, I guess you 08:30.800 --> 08:37.440 say, they are probably falling behind, I guess, at the moment. I guess the main lesson for this is 08:38.160 --> 08:41.520 the people driving live L of M lib C forward are generally doing it because they've got a 08:41.520 --> 08:46.720 particular use case. So, right now, the people who want it on the next Android, Fuchsia, 08:46.720 --> 08:52.880 are the ones driving it forward, I guess, at the moment. So, Mac, you actually want to use it. 08:52.880 --> 08:57.520 As I mentioned before, there is already a lib C available for pretty much every platform. 08:58.400 --> 09:06.560 So, static linking, if you desire that particular point, if you've got an existing lib C, 09:06.560 --> 09:12.560 and you do want the particular properties of the math library, then that's another thing. 09:12.880 --> 09:18.000 I think that that's kind of where it's mostly being deployed in things like Android, 09:18.000 --> 09:24.080 whatever, that sort of thing. Certainly, if you've got a target like a GPU, I say, I'm 09:24.080 --> 09:29.040 saying this with no background noise and will probably be corrected. But L of M lib C might be the 09:29.040 --> 09:35.840 only lib C for a GPU, at least I'm not aware of any other open source ones available on project 09:35.840 --> 09:41.040 that one. And if you're running on an embedded system, I think L of M lib C is the only one 09:41.040 --> 09:47.920 that actually implements the optional fixed point extensions. So, if you want to do fixed 09:47.920 --> 09:53.040 point arithmetic and using the C library extensions, L of M lib C's currently the only C library 09:53.040 --> 09:58.000 that implements them. And of course, yes, it's fun to try new things. So, if you're just even 09:58.000 --> 10:03.840 interested, yes. So, it's also if you're in this platform mode and that you use part of the 10:03.840 --> 10:11.360 platform and overlay mode. Yeah. Is there a still a benefit to have static linking to the 10:11.360 --> 10:18.080 L of M part of the L of M? Well, I think it's done a static mostly. So, the question is is there 10:18.080 --> 10:25.120 benefit in static linking if you're already dynamically linking in overlay mode? Yeah, I think at 10:25.120 --> 10:29.760 the moment you won't get that benefit yet. I think the dynamic, the overlay mode is really just 10:29.760 --> 10:35.520 how can they incrementally develop it? I can get to the moment. But I imagine once if they get far 10:35.520 --> 10:44.320 enough, they'll just drop the dynamic part at that point. Okay. So, this is the overlay mode. So, 10:44.320 --> 10:50.720 for those of you kind of not familiar with the next dynamic linking type thing. So, when the dynamic 10:50.720 --> 10:56.240 link is searched for a search is for a symbol, it always starts the application and then does 10:56.320 --> 11:02.240 breadth first out from there. So, if you're static library, say defines sign-effers, I've got there, 11:02.240 --> 11:07.840 then everything, every shared library and your application will use that definition of sign-eff and 11:07.840 --> 11:15.360 it'll mask whatever depth definitions in the shared library. But if that's the symbols not there, 11:15.360 --> 11:19.040 for example, W men and child. I don't think it's implemented at the moment, at least it wasn't when 11:19.120 --> 11:26.800 I wrote the slides. Then it will go to the shared library and can load it from there at that particular 11:26.800 --> 11:34.560 point. So, this is essentially how you can use L-OVM lib C today to get access to some function. 11:34.560 --> 11:40.400 Now, this doesn't work. It kind of works very well for things like the math library functions that 11:41.200 --> 11:45.840 unless you've implemented a very strange way, don't share state or have hidden things behind the 11:45.840 --> 11:53.280 scenes. For example, there are C library functions that do share state and if you're going to replace 11:53.280 --> 11:57.680 them, you have to replace the whole lot or otherwise you're replacing one independent part, it's going to fall apart. 11:57.680 --> 11:59.840 Very quickly. Sorry, there's a question. 12:00.800 --> 12:10.160 What's the similar difference of the GFC and muscle because, for example, you have a single version 12:10.160 --> 12:15.840 in, you also have a different receiver when it comes to loading something with the yellow and your force. 12:18.240 --> 12:23.680 Okay, so the question was, what's the similarity between G-lip C and muscle with respect to dynamic 12:23.760 --> 12:30.240 linking, that's everything. So, right now, I'll go into a little bit, the library there is L-OVM lib C 12:30.240 --> 12:35.520 dot A and it's just a pure static library. There's no dynamic linker. So, essentially, it's using, 12:35.520 --> 12:41.120 if you're overlaying muscle, you'll use muscles dynamic linker and if you're using G-lip C, it's using 12:41.120 --> 12:47.120 G-lip C's depth. So, I will come to it in a bit. Right now, L-OVM lib C, they're deliberately 12:47.120 --> 12:53.600 not implemented a dynamic link yet because once they do that and they can make it themselves 12:53.600 --> 12:59.280 a shared library, they pretty much have to fix all of their interfaces become ABI stable. So, 12:59.280 --> 13:03.520 so, as soon as they do that, it's basically an omission that they are now mature at that particular 13:03.520 --> 13:10.720 point. So, I think it's one of those things that we won't see a shared, sorry, dynamic link 13:10.720 --> 13:16.800 for a few, well, I don't know when, I know one is planned, but I guess it's going to be, 13:16.800 --> 13:20.160 it's less of a technical challenge, it's more, are we done enough to get to that point? 13:21.120 --> 13:28.400 Okay, so, to actually build it, it's very, very simple. Essentially all you need to do is point 13:28.400 --> 13:35.360 C-lake at the runtime's build and then just say L-OVM, sorry, L-OVM, sorry, 13:36.400 --> 13:44.240 enable runtime's lib C and it will build you a static lib L-OVM lib C. So, one of the things I'll 13:44.320 --> 13:49.280 mention for this image, don't read them too closely because they are taken almost identically from 13:49.280 --> 13:56.080 the docs. So, this, if the top line L-OVM projects lib C docs overlay mode and there's a final 13:56.080 --> 14:02.800 one for host build, they're actually quite approachable and kept up to date. So, it's, well worth 14:02.800 --> 14:06.160 if you want to do it, just look at the docs rather than size, but this is just to give you an idea of 14:06.160 --> 14:11.600 what's there. So, when you build the overlay mode, you've only got the unit tests to do that, 14:11.920 --> 14:19.200 but yeah, in effect all you need to do is you stick the library path onto your linker and then 14:19.200 --> 14:24.880 put dash L-OVM lib C. Now, it has to be called something different because you also need to link to 14:24.880 --> 14:29.520 lib C as well at that particular point. So, that's where you get both of them on your link line. 14:30.800 --> 14:36.480 Okay, so when you build it on standalone mode, then essentially you get one static library, 14:37.440 --> 14:43.760 in this particular case, we want to replace the existing lib C in lib M. So, they're called 14:43.760 --> 14:48.240 lib C in lib M, so that when you do your linker's normal search path, it'll pick these ones up, 14:48.240 --> 14:54.640 not system ones and because I've mentioned there's no dynamic linker yet, then you can't do any 14:54.640 --> 14:59.520 shared libraries at all. So, I think at the moment for something like Linux, you would, 15:00.160 --> 15:04.880 this is kind of your development mode, I guess at that particular, I don't know whether there's that 15:04.880 --> 15:10.080 much use in it right now if you're actually writing an application. I think it's, it's very much 15:10.080 --> 15:17.120 for it, there will be, but it's the sort of, how do you sort of get to that point? And I said, 15:17.120 --> 15:23.760 you know, there's a project along the way to can we bootstrap Clang by using L-OVM lib C in 15:23.760 --> 15:30.960 the speaking button? Okay, right. Okay, so now to actually build in standalone mode, it's very, 15:31.040 --> 15:36.240 very simple, I've just highlighted the bits in purple, where the bits need to change. So, 15:37.280 --> 15:43.440 the bits with compiler RT are essentially to pick up the skeudo allocator. Now as far as I know, 15:43.440 --> 15:50.400 if you don't do that, you basically don't get malach or the heap. So, so you don't have to do the bits 15:50.400 --> 15:55.840 in orange, but if you want the, if you want the heap allocation, then you'll need to put those in. 15:55.840 --> 16:09.840 But again, fairly very simple. Now, what's recommended is to build Clang L-OVM lib C, all in one 16:09.840 --> 16:16.800 go into assist route. So, you can quite easily just say Clang dashed atic from assist route and it 16:16.800 --> 16:22.640 will pick it all up. If you're building, if you're doing a sort of standalone build separately, 16:22.640 --> 16:28.160 then you've got to add all sorts of dash L and whatever flags onto your line. So, that's what 16:28.160 --> 16:33.520 I've put down here is the recommended way of doing a full build and instead of going to the run 16:33.520 --> 16:37.360 times directory, you're going to the L-OVM one, so you can pick up Clang L-OVM lib C at the same time. 16:39.520 --> 16:46.080 So, in embedded systems, so bear metal build is kind of like a variant of a full build, 16:46.080 --> 16:51.280 except you're doing cross compilation. Also, you're not going to build all the things like 16:51.280 --> 16:55.520 POSIX support because you don't know whether you've got a POSIX operating system available. 16:56.720 --> 17:01.760 L-OVM lib C has a bit where you can configure what goes into the C library. 17:01.760 --> 17:08.000 There's a directory called Config for ARM, ARM, ARM, ARM 64, risk 5. And in that, they've got 17:08.000 --> 17:13.280 a list of functions and header files that they want to put that get pulled in. And there's also 17:13.280 --> 17:20.320 some customization that's done to the function. So, for example, printF doesn't use floating point 17:20.400 --> 17:28.640 right now. Erno, you need to provide a function that says where Erno is, because it just doesn't 17:28.640 --> 17:32.720 at the moment there's so many different choices where you could put Erno at that particular point. 17:32.720 --> 17:38.320 And some of the giant tables that you look up tables you might use are taken out in favor of 17:38.320 --> 17:44.800 a runtime mechanism. Now, one of the things that you can do, well, it's well, it's fairly easy to build 17:44.800 --> 17:49.200 L-OVM lib C for embedded systems. Actually, getting it to work is a bit more difficult because there's 17:49.280 --> 17:55.920 no startup code at all. You kind of have to do a small number of activities that 17:56.960 --> 18:02.000 things like, you know, tell L-OVM lib C where the heap is, for example, and it's just a little bit 18:02.000 --> 18:10.560 of link of script stuff. Now, I have got some example startup code at the end in the slides. 18:10.560 --> 18:14.720 So, I'm not going to go through it because it's basically three pages of code, which doesn't look 18:14.800 --> 18:19.920 very good. So, but in many ways, you can look through it later if you want to. 18:21.200 --> 18:30.880 So, what's there? What's missing? So, this is kind of building the headers in studio for embedded. 18:30.880 --> 18:39.520 There's no file star at the moment. You can show that in the example code, get basically 18:40.400 --> 18:45.200 stood in, stood out, see a working. If you've got something like semi-hosting available, 18:46.480 --> 18:51.760 but yeah, there's no floating point print earth. There's no locale. It's sort of 18:51.760 --> 18:56.240 ask you only in the sea type, that type of thing. And obviously, you haven't got things like the 18:56.240 --> 19:01.520 threads, whatever signals just yet. But that's generally what's available. And a lot of embedded 19:01.520 --> 19:05.280 systems, that's actually good enough. You can actually get a lot of small embedded systems working 19:05.280 --> 19:11.680 just with that. Okay. So, you don't want to go down the pre-built route. There are some tool chains 19:11.680 --> 19:19.760 already that are using LWM-lbc. Now, the recipe pie pie co, our pico, the sort of pigweed application, 19:20.880 --> 19:24.880 and there's this tutorial there called sense, which shows you how to download the tool chain 19:24.880 --> 19:32.400 and get things done. That is that project is using LWM-lbc under the hood, and it's got 19:32.400 --> 19:39.440 Arm and Risk 5 available there. Arm tool chain for embedded, which is the project that I work on, 19:40.720 --> 19:46.640 that has got a sort of a libsy package at the moment that you can kind of build for all of the 19:46.640 --> 19:51.840 architectures to that tool chain support. So, like pretty much all of the arm that you might want to 19:51.840 --> 19:59.280 run embedded device on, that's pre-compiled at that point. At the moment, we only support C. Currently, 19:59.360 --> 20:06.400 you can't build libsy plus plus with libsy out of the box. There are some, there are some C-made 20:06.400 --> 20:11.760 configuration you can do to take to cut it down, and there are, it needs a few bits of hassle 20:11.760 --> 20:16.560 on the IO functions to be able to build. So, at the moment, we're kind of waiting till that's 20:16.560 --> 20:23.280 available out of the box, but I think LWM-lbc plus plus coming, it will be soon. Okay. So, 20:24.000 --> 20:30.560 bringing it to a close. LWM-lbc is a new loopsy on the block, that's the thing. It's 20:30.560 --> 20:37.200 complete enough for many use cases, and in some cases it may be the best in some niches, 20:37.200 --> 20:44.560 particularly GPU, fixed point, or if you need the stability of hassle library at that particular point. 20:45.360 --> 20:51.040 And you can get, well, I say it's fairly simple to build if you want to try out, and it's 20:51.120 --> 20:56.240 available in pre-built form, if you want to. And I think that the GPU port is a good demonstration 20:56.240 --> 21:02.720 of how configurable it is. Okay. So, I'll go to this really, really quickly, because most of this 21:02.720 --> 21:07.920 is just telling you things that you might want to know. As a libsy channel, libsy channel on discord, 21:08.960 --> 21:15.520 and there's a boat on GitHub. It's open to contributions. What we're, there's a whole list of 21:16.000 --> 21:22.320 starter issues marked out. There's a libsy tag on the issues page where you can find out 21:22.720 --> 21:27.120 things that need to be implemented. There's a whole load of things in a contribution guide about 21:27.120 --> 21:33.120 what's a good starter sort of thing. There's a monthly community meetup. I believe that in 21:33.840 --> 21:38.640 next week is the bit where it's on its four-week cadence, but it's in the LWM calendar that 21:38.640 --> 21:44.320 Chris stuff mentioned on the opening thing. It's often mentioned in the embedded developers meeting, 21:44.320 --> 21:50.560 which is on the in the same time slot, but just offset by a couple of weeks. Okay, so don't 21:50.560 --> 21:54.800 worry about too much. These are in the slides if you want to do that. But then one of the most 21:54.800 --> 22:00.160 interesting links on there is the LWM libsy already maintained a list of talks that people have 22:00.160 --> 22:05.440 done on LWM libsy. So, if you want to find everything out from there, that's the place to go to 22:05.440 --> 22:11.840 on that one. And the actual documentation is fairly good for LWM libsy. Unusual for LWM projects. 22:12.320 --> 22:17.760 I'll take a look at that. Okay, so I'll stop there. And if there's any gone, gone, 22:17.760 --> 22:21.920 any questions, we've got about a couple of minutes, I think. 22:26.640 --> 22:28.160 Yes. 22:28.160 --> 22:32.160 Are there any questions to support back the assembly? 22:32.160 --> 22:41.760 Because the question was, is there any plans to support web assembly? 22:42.720 --> 22:48.480 I can't remember off the top of my head. What I suggest for that is go and have a look at the 22:48.480 --> 22:52.320 document and see if anyone's mentioned it anywhere. I don't know whether there's anybody actively 22:52.320 --> 22:58.320 working on it, but I don't see why not. I guess the main thing I'd say, LWM libsy is currently 22:58.320 --> 23:03.520 being driven by the people, generally people have got a use case quite specific. And they're 23:03.520 --> 23:09.360 just, they're chanting, how can I implement enough in LWM libsy to get my use case to work? 23:09.440 --> 23:13.520 So, generally it would be requiring, if someone from the web assembly wants to get involved, I think, 23:13.520 --> 23:22.160 yeah, that would be great. The back, yes. 23:30.880 --> 23:32.400 How does it work? 23:32.400 --> 23:38.720 Yeah, okay, so the question here is, LWM libsy is written in C++, 23:38.720 --> 23:44.880 how does that work? Because C++ often does things behind the scenes. It might call out to call 23:44.880 --> 23:50.160 out to some API library function that might, you might end up with circular dependencies on there. 23:50.160 --> 23:57.280 So, there is actually a whole CPP call, come talk all this. It's only like the challenges of implementing 23:57.280 --> 24:02.880 libsy in C++. So, if anyone wants to details, there's a whole hours to talk on that. But I think 24:02.880 --> 24:07.680 roughly what's speaking is they've kind of implemented a subset of the C++ standard library. 24:08.480 --> 24:14.960 In, that's specifically written to be dependency free, and they implement in terms of that 24:14.960 --> 24:20.080 library that's internally. So, within the C library there is a C++ library, that this is used in 24:20.080 --> 24:21.760 eternal things. Yeah. 24:22.960 --> 24:25.280 Have I got time for one more? One more? 24:33.280 --> 24:37.600 Right. I mean, I think that would be down. So, the question is, is there 24:37.600 --> 24:44.720 awesome unit tests, but what about sort of full application tests? I mean, I think for the moment, 24:44.720 --> 24:51.360 in terms of the LWM repository, it's mostly unit tests and there are similar to the libsy 24:52.160 --> 24:56.560 plus plus tests where there are some sort of, if you build it in host mode, you can run some 24:56.560 --> 25:03.280 full tests, but there's still very much on the unit small test type things. I think LWM libsy 25:03.360 --> 25:10.560 is heavily reliant on first testing at the moment, I think, to do that. I think the application 25:10.560 --> 25:14.800 testing is, at the moment, it's mostly been done by the people who are implementing it, but yeah, 25:14.800 --> 25:20.320 I get your point. It's most, there's not a lot of that in the LWM project as far as I know right now. 25:21.520 --> 25:22.480 Okay. I better stop there.