 Okay, well, I guess I might as well start on time. Hopefully I finish on time. Yeah, my name is Chris Freed. I'm a Meta software engineer at Meta in ASIC firmware. Technically, ASIC platform software foundation. And thank you to my team who showed up. Yeah, we're gonna be talking about using Thrift and Zephyr. So just a quick show of hands. How many people have used Thrift in the room? Anybody? I know you guys have. I already know you have. Cool, very cool, thank you. I mean, did you use, have you used Thrift? No. Oh, okay, well, soon, soon. That's okay. So just a bit of background about myself. In the Zephyr community, I'm POSIX API maintainer, FPGA driver maintainer. There are more maintainers that I'm learning of. I forget about these sometimes, but like hash utilities, Thrift, collaborator in C++, C, GPIO, 802.15.4, TI simple link platforms. Mario's just shaking his head. He's like, you gotta do less. Mario's my manager, by the way, sorry. He said he was gonna make jokes and make me laugh, so I hope so. I've been a GSOC mentor. This is my second time, so I'm quite happy about that. I'll talk about GSOC a little bit more in a bit, but also I'm a TSC member because Meta has been really awesome to sponsor this event, so thanks a lot, Meta. And of course, this is just a big word cloud of things I've done in the past. I have not modified this since last year, so if you saw it last year, it's the same thing. And like before I get into technical details, I just wanted to say even more about myself, which is like probably oversharing, but you know, so this embrace neurodiversity shirt which I wanted to wear, but I actually forgot to order because of stuff. It's just funny because so I'm 42, ripe old age of 42, just now I have ADHD, which everybody who knows me, they're probably thinking this explains so much, yeah. Anyways. Yeah, so like at the same time, I just wanted to send it a message because this is a good platform to send it a message, especially to my own kids. If you feel different, that's okay. Talk to the people who love you. Talk to your doctor. Life's challenging, but at the same time, we have a superpower. It's called hyper-focus. That's how I got my slides done. Anyways, there are a lot of people who are really successful in the world who have ADHD, so don't be afraid. And of course, these are the things we're gonna talk about today. I decided to keep it short and sweet. Hopefully leave a bit of room for discussion and hopefully I'm not talking too fast, so I'm gonna slow down a bit. But yeah, here we go. So obviously, what's Thrift? I mean, we've got a few people who've used it in the room, but I'll give a brief introduction to that. A little bit about how Thrift appeared in Zephyr. GSOX involved in that. That's the Google Summer of Code for those of you who are unfamiliar. And then just kind of a status update and kind of say what's left to do. So yeah, here we are. And I'm not making money from these, but these are really cool stickers. Some of them are on my other laptop, but yeah, I love the swag. There's a few more spaces on my laptop, so if you have stickers, please feel free and I will put them on here. Yeah, so Thrift is a rumor procedural framework. I hope a lot of people understand what that means, but if not, that's okay. It works on every operating system. It's kind of framed sometimes, kind of buffered sometimes. It does a few different things. It supports lots of different, what they call protocols, which I kind of prefer to refer to as encodings. So like binary, compressed binary, I kind of like calling them encodings, but that's okay to each their own. And then of course we've got the sort of other transfers that they use like TLS as one. Zlib is another one, or Zlib, depending on your preference. And then of course we've got the client server code, which is generated, so it's a code generator. It's an interface description language, which sort of looks like software-y stuff. And yeah, and then it sort of does your communication for you, which simplifies a lot of things. So a bit about remote procedure call frameworks, because that's like super boring. I'm sorry I have to do this, but I just want to make sure everybody has the same platform to stand on. So as I said, Thrift is a remote procedure call framework with an interface description language. If you're as old as I am, or possibly older, there's a very high likelihood that you remember ASN1, which is abstract syntax notation one. It's an ITUT standard, and then it became an ISO standard. It's pretty highly used in telecommunications, but also elsewhere. You'll find other things like, obviously like radio links, television links, modem signaling sometimes. Sort of, they cover things, the ITU for example as well, will cover things like UART encodings, like HDLC if you're familiar with that, and that sort of thing. I say this, and I really hope I don't offend anybody by saying this, but a lot of times people will all say, well I only had like eight or 16 bits to transfer, and I don't foresee that ever changing, and I will never, famous last words, who started a project and said, I'll never need to transfer more than eight bytes of data to describe my system in entirety. Never said no and ever, right? Maybe you said it, but in a lot of cases, it ends up being wrong, so that's what I refer to. You could do bitwise information sharing where you're saying, like I've only got these three states, and I'm gonna use a couple of bits to encode that, but that's what I call bitstuffed handwritten protocols. So that's the sort of thing where you wanna avoid if you wanna scale your communications protocol, right? So it's okay if like you do one thing, and it's like it's only ever gonna do the one thing ever, but if you're doing something like reading metrics from a device live, you're gonna wanna have rich, a rich set of information, a rich set of structures to work with, so. Another thing about RPC is it often handles the errors that are normally involved with complex data transmission, so a lot of people have probably seen someone trying essentially to reinvent TCP using UDP. That's like a classic example. They're saying like, oh, my link is perfect. I'm never gonna lose any bits of information. Nothing's ever gonna get corrupted, or whatever, I know that Ethernet has it, but it's sort of the same idea, like I'll never lose a packet, you know? No, but you get like the retries, that sort of thing, kind of for free, and that's where a lot of people make the mistakes in boilerplate code. Yeah. Anyone with a communications background, I'm sure, right? So obviously ASN1 is not the only thing. Sun RPC, does anyone remember Sun RPC? Oh, there we go. Yes, I knew that, I knew that. Yeah, so it's been part of G-Lib C forever. It was invented by Sun Riker Systems, not surprisingly. It's, it was essentially like a code generator, so you have RPC Gen as well, which takes some sort of input in. Actually, it's right here, so I got my mouse handy. So this is a little snippet of what you'd expect to feed into RPC Gen. It looks like software, so it's an interface description language, but it's actually, it generates your code for you. So, and here we would have a procedure, and the problem was with Sun RPC that, yeah, they required this nasty thing at the end here, which was the version. And not everybody wants to version every single procedure by hand in their protocol. Let's be honest. The other thing that was difficult here is that you could end up having to support multiple versions of your protocol simultaneously by hand again, which is something we want to avoid because that's another pitfall. And that's just kind of a nightmare. It's impossible to maintain. It's prone to being broken. So around the same time, and I say this very lightly, it was around the same time as the downfall of Sun Microsystems. So, I mean, I have an immense amount of respect for Sun Microsystems. They had some of the most bright people on the planet. They contributed so much to open source, but somewhere along the lines, things got messed up. But things like protobufs, which actually proceeded thrift, which then later went into GRPC. There was something internally, obviously protobufs was from Google. There was something internally at Google called Stubby. That was an internal version of, sorry, GRPC. But that was not open sourced. Thrift came after protobufs. So it kind of hit the world a bit earlier. So the main concepts with protobufs were just get rid of message versions because they're prone to breaking things. Don't reuse tags. And sorry, I forgot this bullet point. But by tags, I mean tag length value, which is just kind of like an intuitive way to encode things. You've got your tag, which identifies the object that you're trying to convey like the, will either be like a field in your structure or something like that, or like a known item. And then length, obviously is the length of bytes and then the value itself. So it could be UN64, it'll be eight bytes. Yeah, yeah, yeah. All right, I missed this bullet point too, sorry, I'm gonna backtrack. Some other things that use TLV. Netlink, which is pretty extensively used in the Linux kernel. If you've used, and if you've done any tooling for network interfaces in Linux, then you've used Netlink, most likely. And you've had to hand code your RPC things, functions, your client and your server. So Netlink is actually one of those weird ones where the code isn't generated for you, which is, I find a little bit heartbreaking, but what can you do? Another one is MISB, which stands for Motion and Immigrant Standards Board. So they also went with the whole tag length value thing. That's actually used in MPEG, believe it or not. So MISB standards, which is like a military thing, is kind of built right into a lot of the video standards that we see today. I did MISB and Thrift, which was just kind of a mind blow for me. It wasn't the first time I heard of Thrift, but I was able to get it done and I was like, wow, this is really cool and I really enjoyed hacking Thrift. So at that point, I kind of got a little bit more involved. I missed the last one as well, apologies. Again, neurodiversity. So one of the nice things about Protobuf's Thrift GRPC answer thing is that by following these very simple rules, you actually get guaranteed consistency of your protocol from one revision or commit to the next. And you can actually verify that with fairly simple tooling. So let's move on and I think I'm good for time. This, again, I have tremendous respect for Sun Microsystems and any of my colleagues and probably a lot of the audience is aware that at Facebook, we in here, sorry, Meta, my mistake, I started one of his Facebook, that's never real, but Meta. Meta sits on the old Sun Microsystems campus, which we call MPK. And behind the, let's see if I can get my mouse over here, behind the famous thumb, which is one hacker way, we still actually keep the Sun Microsystems fine and that's to remind us that even if you're giant, and hugely successful, you still have to be able to support yourself, support your own ways, continue to innovate and be introspective and see where you've done things wrong and make better decisions. So a little bit about Thrift, as I said, Facebook, Meta. It was created in 2006, 2007 and inspired with protocol buffers, of course. It was open source almost immediately after that because internally they said, well, why would we just keep this to ourselves and just sit on it? Let's share this with the world, right? This is how tooling should be, we wanna make our lives easier, we wanna make everyone else's lives easier too. Thrift is used ubiquitously everywhere within Meta, almost everywhere. I'm not sure if it reaches out onto the very, leaf edges of everything, but definitely within our infrastructure. It's actually even been adopted by a number of companies and I didn't wanna write this down because I just found this information on the internet. But just to name a few, like Uber, Slack, Venmo, Evernote, Twitter, Netflix, and in terms of software that runs on your device, the one that I'm familiar with is GNU Radio. So they had kind of pulled in Thrift for a brief period of time for experimentation. It's been too long since I've done software to find radius, so I'm not even sure if it's still there, but I found that very cool. Now let's see. So it is obviously, we've got some pretty important things within Thrift in terms of permatives, you get your standard Boole, N2, N8, N16, N32, N64. But then we've also got these really incredible rich data structures. We've got lists, sets, vectors, maps, structures, enumerations, all the things that you would expect in a high level programming language. You can embed things within other things. You can have parametrized things. So I mean, it goes on and on. It's really what you'd expect when you're conveying information from point A to point B. You wanna encapsulate that in the correct way. So this kind of allows you to do that. It's very similar to protocol buffers, in that sense. There are a couple of key differences which I'll highlight in a few minutes. Of course, we do binary, compact binary, but also things like JSON. And in terms of the actual transports, I guess they call them low-level transports, there's HTTP framing. If you've got a really big payload, then you can break that down into multiple sizes or chunks. So that's called framed transport. Zlib, which is really cool for low bandwidth links, like 8 or 2.54, and so on and so forth. So one of the interesting differences between protobufs and thrift is that in protobufs, you, I think you're limited to one argument to your procedure, whereas in thrift, you can actually add several arguments. This is kind of cool. We also can throw, which is a little bit different than protobufs. I think protobuf expects you to return an integer that's possibly an error. Again, it's been a while since I used protocol buffers, but that's another slight difference. Another big difference is that we actually build all of the tools that you need for your transport right into our library. So for the most part, you don't have to reinvent anything. It's been a while since I've done GRPC again, so apologies if that's not the case anymore. But from what I remember, the transport has kind of looked up to the user. Just in terms of numbers, we support all the operating systems, 27 program languages. I think there's like seven to 10 little of the transports now. And the list of higher level transports just grows. So I mean, the number of program languages that we support is growing as well. I don't see it stopping. So I'm gonna return to the bottom point here in a little bit, Facebook, we obviously donated thrift to the Apache Software Foundation shortly after writing the white paper in 2007. But then we forked again. And you might just think like, why did we fork it? Forking's bad. Like, you can never fork things. There can never be too many forks, so I'm just kidding. No, we forked it for a good reason. And that's a separate project called FB Thrift, which has this interesting logo on the sides. So up here, we've got a little bit of a frame that you can look at. Oh, sorry, that's my screen. Yeah, here's a bit of a frame to just kind of highlight how things are packed under the hood. And then here's like a little snippet of a dot thrift file. So you've got enums, a struct, and a service. The service is, you know, your service and your procedures live in the service. So yeah, let's get into thrift inside of Zephyr. Again, stickers, I'm not making money from any of this, but I think this one is my favorite. Does anybody remember Z-Boys, Zephyr Skateboard Company? Anyway, so yeah. This is the actual official Zephyr sticker. And if you don't have one, I can give you one, or Brett can, please take some. I just put this one up here because thrift is one of those things that is awesome enough to have to have like a protocol disector for wiresharks. So you can easily create a PCAP out of it. And everybody loves PCAPs, right, so yeah. So I really wanted to do this all by myself, but I don't have infinite bandwidth. I know Fabio does. I know if he's in the room here. So that's why I was just trying, in the last talk he had. I was trying to give him some ideas, but I don't have infinite bandwidth. But I thought, hey, if I can't do this, maybe I can mentor someone in the Google Summer Code, and that's what I did. So our contributor, Yang Mei, who's originally from China, his GitHub is STD Electronics. He did the immense undertaking of porting this to thrift. It was a huge job. I'm not gonna lie. It was stressful. I was co-maintainer along with Stefanos, who's our libc maintainer and our C++ maintainer. He's a really smart guy, very helpful. So Yang implemented a bunch of features. Obviously the things that you kind of take for granted, like binary protocol, compressed protocol, that was pretty easy to implement. Zedlib, could anybody imagine Zedlib fitting onto a microcontroller with 4K of RAM? The actual Zedlib? Oh wow, that's impressive. Wow, I'm gonna have to talk to you later. But we found it pretty much impossible, especially with, okay, here's the question, with the C++ application. Okay, so yeah, again, we chose the C++ approach because it was probably the fastest market, so to speak. And because the C implementation for thrift linked to Zedlib, which is LGPL, and I'm not a lawyer, so I'm gonna stop there. Of course, Zephyr's Apache 2.0, so we wanna try and keep that aspect of it. So in any case, Yang was clever enough. He did this all by himself. I am honestly impressed. He found this library called UZlib, which was originally written by Paul Sikolowski, or P. Thalkin on GitHub. Instantly, the previous POSIX maintainer, prior to me. There's a bit of a gap. I'll go into that tomorrow. And he kind of put it together with some other stuff and called it music with a Zed. So kind of clever, it fit, and that's all we cared about. So what Zedlib transport does, is it basically compresses your payload so that you can see less bandwidth over band limited or radio links and that sort of thing, which is important for the IoT operating system. And then of course, regular thrift uses open SSL under the head, so. Obviously we're not gonna put open SSL on a microcontroller and Zephyr was great enough to already support Mbed TLS. And Zephyr's approach to Mbed TLS is a little bit different and that they have a special socket type. So you don't just get like AFINET or AFINET6, I think it's, or no, sorry, it's one of the domains. So I think it's, you'd have to go out and have a look. I can't remember everything, but it's like TLS, something or other, something or other. So it's a clever way to tell them that you want to use an encrypted channel. And it supports one way authentication and mutual authentication, so it's quite good. Young somehow managed to get all the tests we'd surpass for every architecture. We don't do that on every commit. Obviously we just run a couple of chosen ones. And it's mainly in Kimia right now. We don't have any hardware hooked up upstream. And of course, how do you know that it works? Well, I'm not gonna click on it right now, but there's this, I invite everyone to click on this. This is just kind of a little kitchen sink protocol called thrift-test.thrift. So it includes everything, it exercises every code path, like enums, structs, nested structs, doubly nested structs, vectors, lists, sets and everything. So it's pretty, it's pretty far-reaching. We get some good coverage. And of course, the test suite, you'll find upstream and Zephyr's repository. And then finally, we've got a couple of samples where it's really cool because you can run the server or client within Zephyr and we're Kimia only right now. So you have to actually go through the process of creating your network sockets connected to Kimia. And then whatever your host operating system is, you'll be able to run a C++ application. You could even run a C application or a Python application or a Rust application or there's an infinite number of possibilities. But yeah, that's all supported. And it's in the documentation upstream. And yeah, we made it to Zephyr 3.3.0, which was released at the beginning of the year in January. And I actually should highlight, this is without the Zlib or UZlib. And the reason for that is because Zephyr does not yet have a compression decompression subsystem. So for anyone out there who's interested in being a maintainer or contributor, if you're interested in compression decompression, that's a really interesting area. And I think Zephyr would benefit tremendously. So yeah, still experimental because just because it's functional doesn't mean it'll work really well on every platform. Before we get to the next slide, actually, I mean, there's the obvious question of like, what information can I send and receive in thrift? And does anybody know the answer to that by any chance? Anybody? No? Okay, yeah, it's like anything. Anything you can think of, anything you want to send. You can send strings, binary or whatever, whatever, it doesn't really matter. Whatever you can conceive of, whatever your application demands you can send and receive. And it's transport agnostic. So that's kind of nice. I'm not gonna give away too many secrets. And I'm just gonna drop some hints here, but of course, thrift is transport agnostic. How can I use it? Well, really, anything that can be represented with a file descriptor is the easiest way to start. So like a socket, if you're on Linux, for example, you can just use a file, a text file if you want. Within Zephyr, we're basically limited to sockets at the moment. Socket pair is another one. And of course, in Linux, everything's a file, so the world's your oyster, but on the Linux side, you can think, well, what else can I represent as a file? And just dropping some hints, I'm not gonna elaborate on this, but you know, like DevMem. There's a lot of interesting things you can do with an integer file descriptor that points to DevMem. DevGPU, sort of a similar situation. And I don't know how many people are interested in hardware acceleration, but the Linux kernel upstream just last year, officially got a new major for the first time, and I don't even know how many years, like 10 years, something like that, not sure. But yeah, DevExcel is the new one. So that's for hardware accelerators. Within Thrift, of course, we've got sockets, or sorry, within Zephyr, we've got sockets, but we've also got this interesting little wrapper around memory, which could be like DDR, it could be SRAM, it could be special, like DMA memory, sort of like tight couples, that sort of thing. So in Zephyr, you may wonder, can I put an integer file descriptor in front of something if I wrap it in the right thing? And the answer is yes. So I'll invite everyone to visit this label later, sorry. But the FDTable facility within Zephyr is kind of interesting. It gives you a bunch of things like I octal redrait, which you'd expect from a normal virtual file system, sort of thing, and so if you've ridden a Linux driver, you're probably quite familiar with that, but we support something quite similar in Zephyr and I can assure you it's actually trivial to implement, so again, I don't want to spoil anything, but if you, by chance, happen to attend the keynote there's more warning by my manager, Mario, right here, for Metta, he's like shrinking away. No, please attend, there's some interesting stuff that he'll announce, and we'll elaborate more from there. And of course, I'll shameless self-promotion, if you're here on Thursday as well, I'm doing a POSIX talk, so. So, integration challenges. Oh, this didn't render properly. It did not, so, I'm gonna, yeah, I'm gonna start from here, but this is kind of the part that makes me sad, and it's a fact of life, C++ can generate blood and binaries, that's not a surprise. And of course, Zephyr's unfortunately got partial C++ support, so the whole roadmap is here, and I'm a collaborator, really close with the maintainer, we're working very hard to improve everything, and I know that there are a lot of people out there that have been waiting for features for a long time, so. So for example, support for standard threads, this thread, that sort of thing, is lacking, and that's because it depends on actually P threads, believe it or not, POSIX threads, with the fastest, or I guess I should say, the path of least resistance is through POSIX threads, that's just because we use the standard shual chain thing, G thread POSIX.h. But as soon as you implement that, then you get standard retext, standard condition variable, standard semaphore, binary semaphore, counting semaphores, lock guards, all the really fun stuff, so. And then of course, the nice thing about that is that your applications just work when you bring them to Zephyr. So yeah, again, we need G thread POSIX to be supported and that falls on me because I'm the POSIX maintainer. And yeah, I'm just listing the issues here for reference for anyone who's downloaded the slides. So please take a look. Yeah, we basically wanna get POSIX threads working with a null P thread attribute because that would imply you automatically allocate your thread stack. And that's how a lot of these threading things work. Outside of Zephyr, inside of Zephyr we usually just statically allocate our thread. I'm gonna try to save like a few minutes at the end here so we'll speed up, but yeah, this is really weird. This is a really funny story by the way, the poo pineapple emoji. My team, our team low is the pineapple. So whenever we see something good, we use the pineapple emoji. And I wanted the opposite of good and this happened. I just stumbled upon it, it was amazing. So some more integration challenges. At this point you're like, why did I come to this talk? No, I promise it gets better. Yeah, so event of D had a major problem. I fixed it before 3.4, which is released by this gentleman right here, Josh. Yeah, so at the same time, like I fixed our improved performance of event FD by a factor of 10, which is awesome. That's all we love. Yeah, so we used event FD inside of the FD server, which is necessary if you want to use integer file descriptors really well. Again, we don't have a compression decompression subsystem, the code size, again, the C++ is huge. That's not something you can get away with easily. And then I actually almost got this to fit on ESP32, but in any case, I was really happy that Young was able to get everything finished for GSOC. So status update, and this is actually where it gets better. It's not all sad news. So for those of you who walked out by, you missed out on the good stuff. Sorry. Yeah, so here we go. Yeah, so there's a whole other, there are so many engineers at Metta, and like way back in 2014, they're like, hey, let's work through it again because we like work. But all these people are way smarter than me, and they could do stuff that I could not. So this is way before I worked at Metta too as well. So they've worked at major enhancements to the C++ implementation and thrift over the Apache version. It's fully asynchronous now. Major gains, and you can see down there a friend of the numbers, but we switched to the Google test framework instead of boost because boost is, let's get rid of that. And then of course, standard coroutine, which was like wicked. And ironically, we don't actually need threads if we use coroutines, so it's kind of funny. But you can imagine that that reduced the code size, reduced the runtime code size, RAM size I should say, and sped things up significantly. Also like a little bit of a memory for reduction in terms of strings because we're using standard string view and zero copy buffers, which is a really interesting feature of this library we have called folly, which is also open source. So like Metta loves open source. Even more improvements recently, and like this is huge, you can see this. Millions of queries per second, of course like I'm just talking no up, but still it's pretty significant. Like major step up, major step up from the original not blocking server to the thrift too. So these people are way smarter than me, and I'm just saying, good work guys. Beyond that, there's one thing that I'm actually, I hope I have enough time. Yes, perfect timing actually. This is like, this has never happened to me before, ever, where I've left five minutes for questions. So this is good, this is my last slide. Something I'm like, incredibly proud to semi-announce because it's almost done, and then this is something that I've been working on for about four years. I was doing it as a contractor before joining Metta. I've been doing it weekends and evenings now then. I don't have a lot of minutes to dedicate to it, but it is like by far the thing that I wanted to contribute most to Zephyr ever. And this is what I heard this morning. Flavio from Intel, thanks. I'm gonna thank a bunch of people, but Flavio and I have been collaborating on dynamic thread stacks with Zephyr threads for the last couple of weeks, just because NOS happened to say, oh, Flavio would really think that is cool for the thing that we're working out on. You guys, you work together, you don't. And I'm like, yeah, that sounds like a good idea if I can get someone else to fix my backs. So as it turns out, I had this almost entirely working at the beginning of the year, and then I re-revved based on some review feedback and I broke it and I didn't know how I broke it and I didn't have enough bandwidth to go back and look at how I broke it. So within a couple of days, Flavio is like, oh yeah, this is your problem right here. I'm like, yep, that's it. So he had it working just a couple of days ago with user space and this morning, literally this morning, he said, oh yeah, just apply these fixes, rebase and all rebase and yada, yada, yada. I woke up this morning, he's like, it's all green. I'm like, what? So I mean, to me, this is incredibly exciting and I hope everyone else feels that this is really exciting too. I wanted to also thank Andy Ross, obviously Flavio, Danny along from Intel, Andy's now at Google, a lot of others, Stefanos very clearly, he's been a huge supporter, Keith Packard too, really, really amazing people and there's a whole bunch of people on GitHub who have been providing really good encouragement and feedback and so on and so forth. But to clearly spell it out, this is Kermit by the way, I don't know if this is like, it's not easy being green as he would say. This is Kermit doing the jeffery, he's like, ah! So yeah, but to clearly spell out what this means, it means that Zephyr can now actually get proper support for POSIX threads and get proper support for C11 threads, according to the ISO standard, proper support for C++ 11 threads, according to the ISO standard, as well as virtually any of the language because I don't know what other things use other libraries but that means like Rust, Lua, Python. So I hope everyone agrees that this is very big and I cut into the question time but that's my last slide, thank you very much. Questions please. Oh, no questions, okay, see you later. Just kidding, I'm just kidding, thanks. Tom, Hannah, the Mogamon Holdings, I'd have a question, please. I'm a bit confused, first of all, I really liked the numbers, it was a very interesting presentation but, sorry, I'm a stupid electrical engineer. Now, can I- I'm a electrical engineer too! Can I, okay, high five, in the sea of software, there's two of us. Well, to, then, sorry, then it makes, I thought it's just me because I'm in the sea, okay, either way, the question is now, if I want to, let's say, if my wife wants next week to start a new project using Zephyr with a, would you already suggest her to use Thrift or not yet? So, right now, as I said, it is experimental and we have an actual cake and fig symbol for that. It's not ready for primetime yet. I would say it's probably more research-oriented. If you wanted to, like, hack it and make it better, yes. If you wanted to, like, I mean, you can do Thrift on your desktop, for sure, you can do it on, like, your mobile phone, it happens all over the place, you can do it everywhere. But within Zephyr, within microcontrollers that just have, like, a few kilobytes of RAM, I mean, I don't know your wife, I'm sure she's very nice. Maybe she's working on cloud infrastructure with gigabytes of RAM, in that case, sure. No, no, I think it's an embedded system. Embedded, yeah. So, you say it is not experimental, so it would require significant amounts of software competence, which we honestly don't have in the company. Yeah, so if you're running embedded Linux, then yes. Yeah, of course, embedded Linux. On Tifu, no, on Tifu, no. Yeah, so Linux we're talking about megabytes, gigabytes of RAM, but Zephyr kilobytes, probably not. No problem. Over in the corner. Hi, I just had a question regarding the, like, this Thrift stack. Can you explain on a particular reason why it requires threading? Like, a dedicated thread? Yes, absolutely. So, the original implementation, which was open source, is called Apache Thrift. So if you go to, it's actually on GitHub, just go to HTTPSgithub.org, or com or whatever it is, slash Apache slash Thrift. Then you'll find Apache Thrift. We have our improved C++ version, which is under Facebook slash Thrift, or FB Thrift, I should say. So the original implementation was very, it just farmed everything off as threads. If you want to do, like, asynchronous, then you're required threads. I think there's an extra thread required, even if you don't want to do asynchronous. And threads are very costly for an RTOS like Zephyr, where you're expected to run tiny microcontrollers. But, of course, the improvements that we've made internally to Apache Thrift are substantial co-routines, shared stack. It's amazing. And that was actually my very first question when I spoke to the implementers who had done this work over the last seven years. So good question, thank you. So, like, okay, let's go with Thrift. Like, I physically can't use Thrift in a blocking manner in my own threads, then. I have to have. Oh, you totally can. Yes, absolutely, yeah. But if you wanted to run, like, a server and just have the code just for it. Yeah, there seemed to be like a focus on threading and then on Zephyr specifically. Yeah, that's right. Because as a code generator, Zephyr gives you a bunch of code and that code, like the Apache Thrift version of it, has threads built into it. So, like, our Thrift server, T server, socket server, for example, has a couple of different threads, which are dirt cheap on Linux or any other operating system with megabytes or gigabytes of RAM, but on a tiny microcontroller. So it was possibly like a design choice made early on that worked, but as we want to get Thrift working all over the place for little things with very little amounts of RAM then. It was probably not the right design choice for that, but now we have FB Thrift, which actually fixes that problem, so. Does that help? No, not really. Oh, sorry. No, no, well, yeah. Yeah, it's just a client implementation. I'm not sure I understand. Well, the client side, no problem. Like, if you're running, like, are you talking, what operating system are you running on the client? It was Zephyr. Okay. I'm curious in Zephyr. Yeah, in that case, you don't have any problems. It's really the server that's gonna be using the threads. So, yeah, no problems. Okay, yeah. Sorry, thanks for clarifying that. Okay, okay. Good, good, good. Do we have any other questions? One more. I think that might be, I don't know if we're at time or anything, like, I actually didn't even see that. You mentioned a few significant differences between Google RPC and Thrift. One of them is that Google RPC is basically from the green layer up in your presentation here. Yes, I believe so, yeah. Yeah, and another one is that Thrift is using exceptions while Google RPC is explicitly not using exceptions. That's right, so in the C++ version, or in any language that supports exceptions, like as a first class citizen, re-enable that. But obviously in C, you can't do that. So, the default C generated code links to Glib, which has its own exception-ish mechanism. Sorry, I think I might have not let you finish there. Was there another component to that? Yeah, from that perspective, if I compare the two, then I think that Google RPC would be a better fit with Zephyr than Thrift maybe. From that perspective, yes. One of the features that I'd really like to see in Thrift is actually like an ISOC code generation target. I was planning on working on that years ago when I was working on the MISB thing, because for that exact purpose, it was a safety critical system. You can't have exceptions. You really just have to rely on integers and errors and that sort of thing. So, I'd personally like to see ISOC as a code generation target. So, would probably work for you too, I assume. Yeah, good. Any other questions? Okay, well, thanks so much for attending. I did not think this room was gonna be so packed, so.