 So the first disclaimer is I'm not a maintainer in Zephyr. So this is just my journey from Linux world into started working with Zephyr and then how do I become a contributor? And like this is just my view about my contribution side of it. So the actual contribution guidelines and the latest updates, please follow the documentation in Zephyr. So that's the first one. And the second one is there was a talk from Carlos and Marty Boliva and earlier this year in Zephyr Developers Summit on behalf of Nordic. This is exactly the same topic like say they have been the patches must get merged in Zephyr. So this is a minor deviation in terms of comparison with Linux apart from the most part of the presentation is like you feel the obligated most likely, but I try to be make it unique somehow. So we in Linux primarily work on embedded Linux and as well as for past two, three years in Zephyr artists as well. And our goal is primarily in terms of bringing support for new SOC's boards and deliver solution as build systems and so on. So I myself live in Berlin. So today we speak like this topic is split between like we speak about what we can contribute and what do you need for the contribution and how do you contribute towards Zephyr? So for how do you contribute part like just to differentiate or to make it maybe understandable for the people who knew to Zephyr? I tried to do a contribution on the fly with the demo because just I have prepared it for. And then also what makes the difference from Linux world and what I felt as a real difference comparing to the Linux kernel contributions and then like you would it's most likely same but we see some key differences between them. Okay, so the prerequisites. So we can speak like many things you might know like needed to do Zephyr contributions as a first place like you may need to know the build system like build and what makes the difference between C make to make and you may have the knowledge about K config. So they all can contribute your prerequisites but I don't call them as prerequisites in this particular presentation. So I call Git and you know Git primarily for one or the other way in version control systems. So that's the prerequisites which I call it myself. So also apart from Git, you have to know GitHub to some extent in a way you need to have knowledge about adding how to create an issue, how to create a pull request and how you can contribute to us in terms of communicating with your actual maintainer reviewer in terms of like say how do we do this in GitHub? So which we can see in a moment but apart from this the basics about Git like you must be knowing like how do you want to create a comment branching strategies and then like let's say if you wanted to merge one branch to another you interested in some features from another developer or maintainer then like how do you rebase merge and play around with it and let's say you wanted to bring in some new features which is bleeding edge but then like it's not in the master yet so how do you pull those things? So that's what we're gonna see about and as in the slide says like you there is one prime difference in terms of coming from the Linux kernel world and as well as the Uboot world like when you contribute to the Linux kernel the whole patch sets and as well as the review process go by mail. So completely only by plain mail there is no rich text only the plain text email and then you communicate over the maintainer and then like you send revisions of patches and revisions of patches and finally get it merged so it's completely email based system but wherein like we have the UI and interactive based systems in GitHub and specifically the project is completely hosted in GitHub so the whole system is like based on GitHub and you need to know like what are the things of GitHub like but we touch some basics about GitHub about like how to open it. So before going into what you can contribute as part of the Zephyr Autas like let's have a brief overview like not an extensive one about the directory structure. So what we have in Zephyr Autas altogether like it's just not just the Autas itself like it is distributed across like multiple source control systems like source sources like as you can see the first thing is bootloader wherein like you have currently Zephyr supports one bootloader from the upstream which is also the same Apache 2.0 license based on like MCU bootloader. So that is under bootloader that's the directory structure the prime directory structure under which you have also modules and which we will speak in the next slide and the Zephyr Autas itself. So and then you speak about Zephyr directory structure here wherein if you see the source structure from Linux or Uboot you might already be guessing like okay so these are exactly same structure. So this is what I felt like happy about so because I was coming from a Linux world and then like I was experimenting different Autos and then like I felt this is more optimal like more easy for me to move from Zephyr I mean Linux to Zephyr world. So in here like we have architectural which is same as Linux which is like you have the architectural dependent code which is start initialization exception handling core memory handling stuff in there like we have architecture support for ARM, RISC-5, MIPS and so on. So and also we have both something similar to Uboot wherein you have the board definition specifically for that particular board how do your PCB itself layout and then all your sensor definitions like what are the peripherals which is connected like sensors or any high speed peripherals like USB and how it's connected. So you laid out this whole definition into device tree under a board definition and then we have drivers wherein you have peripheral IP blocks I squared C SPI or DMA all sort of IP blocks which is comes as part of SOC and also you have drivers for sensor which is actually added externally to your PCB not just part of the PCB or SOC blocks itself we also have drivers for external ICs. So you also have you can also think of about like a shield which you get from the market as an Arduino shield and then you place it on top you get an additional can controller which is like maybe from microchip or something. So those part of driver can also people live in the driver it's not just the driver which is part of the SOC blocks. So and then like we have device tree which is the DTS directory as in say like this difference I can say a quick difference between how it's organized in the Linux kernel and in the Zephyr world. Like the DTS actually goes to arc arm boot or arc arm 64 and then the respective vendor and then like you see the DTS in Linux kernel respective but then like we have the DTS directory completely independent in Zephyr and laid out in the same way like as in the board or arm architecture. So we have architecture specific device trees and then you have like SOSI specific device tree and then like a board or SOC family or all these group of things have been living in the device tree DTS directory. And then you have the kernel where in the core part the scheduler memory manager and then the implementation about synchronization permutations and so on within there. And also before modules we speak about samples and test which is most likely similar like say sample application for a specific case but it doesn't cover all the APIs which is provided by DMA or something but it just covers the basic example of how do you use the DMA or how do you use a specific sensor but when it comes to test cases it covers most part of the test coverages which is used for the CI system as well. So that's where the test directory and sample directory varies. So there is couple of other things which is like I can say arc board drivers and SOC you can think about all of them into hardware level developments like SOC related hardware architecture related and then board related. So we have a picture in the next slide and then we can speak about it in detail. And then the subsystem part where you have the TCP IP full blown stack independent for Zephyr and then like complete Bluetooth implementation stack for Zephyr independently and also for the USB and then many other things like OTA management systems and so on like we have multiple other subsystems as well. So the backbone of this whole source tree is like you can think about like say how it's organized boot loaders and then like you have modules under which you have libraries and modules which you can see. So how does it really organized is basically with a tool called West. If you already have any might know the details how it actually clone multiple dependent modules. Let's say you depend on an external JSON library which you wanted to consume for your application. Then you can include your external JSON library with providing the remote URL and where do you want it to place this particular source code in there. So that's the backbone about West and then how do you clone the source code and the same West tool is actually used for the compilation as well. So it's like West is the main tool and it have a subordinate command like wherein initialization update build signing utilities and this is like additional utilities wherein you can make use of it for cloning and compilation and things like that. So you can also add your own utilities together with West. Like there is a specific talk for West in like a couple of years ago if I'm not wrong. So this is about the module directory wherein you have the good side which I can say it's like modules hall where you have I'm not sure if it's visible. Like say every vendor let's say ST Nordic or specific vendors provides their own hall layer hardware abstraction layer which provides the IP block and then CPU related initialization and IP block handling. So those lives completely external thus doesn't live into the Zephyr tree. So which makes a lot of sense meaning you can add additional modules or the changes to the modules or let's say version upgrade from X to Y for the Nordic SDK or let's say STM32's hall layer is migrated from one version to another. Those can be directly coming in place and the respective changes go to the Zephyr side. So I mean this is completely an external vendor repository made in completely external in terms of hall. So you can also think about like libraries which you currently we have like security there is also another directory called security wherein like crypto you have the security libraries and so on. So this is how the source is organized and there is one a couple of key points which I can compare right away with Linux is like it's completely inheriting the K config configuration system and also in terms of device tree we have been using the same thing as in compared to the Linux kernel. So if you wanted to do a layout how your IP blocks is laid out and how your PCB is connected with your peripherals and so on that comes under the configuration sorry device tree part and as well as the K config part that those things are completely inherited or you can think about same thing as in Linux kernel. So that's how you can compare but when it comes to DevConfig in Linux kernel you have a dedicated DevConfig for your board or let's say with your set of features enabled as part of the kernel. So you can compare them with a specific configuration called project configuration which you build together with application which is an exception but you club kernels and its dependencies together with your application and provide a configuration called project.config. I mean like when you compile the kernel you have like a last set of .config file which is like 5,000, 4,000 lines with all the configuration enabled which I'm not speaking about that. So when you before that compilation you enable a specific DevConfig. So that's what we speak about here that is like project config is something similar to DevConfig here. And also we have fragments. DevConfig fragments where technically we apply for like if you come from an October world or Linux world you have fragments applied on top of existing config specifically to enable IPv6 or specifically to enable a specific feature for your own hardware. Let's say I have two different hardware one with the deployment in India and another one deployment in Germany. So where in I don't have IPv6 in Germany but then specific support in India. So I can enable IPv6 only for Indian customer based on this particular overlay. So that's how you can make a difference but as far as the build system is compared the underlying is like make in case of Linux and like previously it was make for Safari as well but it's actually now CMake, more luxury more comfortable in terms of developing in terms of adding additional support and also the whole system build system of under West is under like basically CMake that's the prime difference which I wanted to point out there. So what actually you can contribute? Now you know the source view how exactly it laid out. How are you basic? I mean what are the parts which you can contribute? So the image which is on the left side is basically taken from Zephyr documentation. So I tried showing up in a quick example about how what are the pieces which you can contribute on part of on behalf of the hardware support. Let's say you have a hardware complete PCB assembled ready to use. So what it based out of? Like you can think about bottom approach wherein it could be based out of ARM architecture or a RISC-FI or MIPS architecture but then we've been this part of implementation goes to the architecture dependent part like as I said in the driver in the initial slide course view Zephyr arc you have a respective architecture and it's in implementation let's say initialization sequences or start that as and let's say memory handling and so on. So those part lives in the respectively of the particular architecture. So then based on every architecture there is an IP which is provided like IP block provided by the respective company let's say ARM corporation itself. So they provide ARM M33 or let's say M4, M0 and respective and then like the companies which is going to use as a vendor get this IP block from them and then produce an SOC and then like they could lay out a different family. For example, in case of NRF we have NRF family which is NRF-52 as a different one another one is NRF-91 whereas like STM we have a different families like L0 through F4, H7 and so on. So that's again getting the IP block from the actual producer of the IP and then they use SOC like the SOC meaning not just the architecture itself they lay out all the peripheral IP blocks on their own. They get the IP probably they get the IP block from a different company. For example, can be obtained from Bosch. So similarly they have their own IP blocks clubbed together to form the SOC and then like they have the SOC Serious and respective SOC family. I mean like sorry SOC itself meaning NRF-9160 is the current one like probably you will have maybe in the upcoming life like the 9161 or we have NRF-52840 and then like 805 or something like that. So that's the previous family. So that's like that's a set of SOCs on top of a specific series. So this is how it laid out and then based on that particular SOC you create a custom hardware and you lay out set of peripherals like sensors or let's say industrial interfaces like RS232, 485 and so on. So then you create a hardware something like a development kit and then completely custom PCB for your customer or something like that. So the same way the hardware architecture is laid out in here you can add support for similar things like when you have a custom PCB with support you can add your support in board and then like when you have a completely new SOC which is not supported in Zaffer then you have to add a support in SOC directory respectively. But then like if you don't have the SOC series at all let's say infinite trigo. So then like it's completely unavailable at this point of time. Then like you can add this particular support in SOC series and SOC family respectively and it's actually completely a new architecture called trigo. It's not ARM. So you can then add an architecture called trigo. So that's how you lay out as in the hardware support is concerned. So when you come back to the slide here architecture board drivers and then like you have the SOC directory. So those part is covering back to this particular slide like laid out in the bottom up approach. So that's about the hardware support SOC support and then there is one thing which I haven't covered here like you probably have external sealed or sensors that has also comes under the drivers but I haven't mentioned this. So those you can add like an I2C accelerometer can be added and then like you have to place this into driver sensor and then respective sensor driver then something like that. So that's what we spoke about but when you wanted to add a specific SOC or a new company's SOC and you have an ARM SOC but then like it's completely not in Zephyr tree then you can add a new hall layer that's the hardware abstraction layer if you wanted to because if the vendor provides a hall layer you can do the whole hall layer as an external addition and then consume it. And then like if it is not if you wanted to add completely entry support as like Linux kernel that is also okay. I think one quick example would be what on FM not wrong. They have the complete implementation of all the IP blocks within Zephyr without any hall layer support in there. So apart from which you can also add support for software in terms of core components, subsystem components like for example, we have implementation for DHCP V4 but then we don't have support for DHCP V6 probably you can have like the duplicated address detection and all the other mechanisms on behalf of DHCP V6. Probably if you are interested and then like you add support for DHCP V6 in your network and then you can contribute back to those areas as well. So and other things like samples, test cases, documentations and tooling and adding an external library probably you are interested in like say another Lipsy like we currently use a minimalistic Lipsy by default and then like newly as part of this tool chain if you wanted to enable them and if you wanted to add there is another Lipsy called Picolipsy and like if you wanted to have another implementation of Lipsy itself then you can go with adding them into modules lip and then consume them into this effort tree. So now we spoke about how the source tree is laid out and what you can contribute as part of the whole source tree before going into the whole pictorial representation of this particular workflow I would like to show a quick example of how to contribute. Let me try to bring in here. Not sure if it's gonna work, okay. It's dark mode, I'm not sure if it's visible but still. So basically Zephyr Autos as I said is hosted in GitHub and you can see the project repository here and if you go one step up further you can see all the repositories. Let's say the hall layers and Zephyr tree itself and all the tool chain boot loader and all the dependencies which we discussed so far. So that's where it lives. So the first step in doing your contribution is like forking your repository. Let's say you wanted to, you have to fork this version and then like you can place in your own way. Like say in your private repository or if you're a company and then you wanted to contribute together with your colleagues, then like you have to place, you can play place them into your company or something like that. So for now I'm gonna assume like I'm gonna place in this particular repo and okay. So and then like coming back to here. So I have a clean cloned version of a Zephyr here. So specifically for this one. So for checking what I can contribute I already checked a specific driver with a minor modification, not a major one. Like just to show it. So check page is the same thing from Linux as well. Like you check for the code alignment, styling, sign off check and all the basic checks. So when I check the whole, let's say all the sensor drivers, you say like a lot of, you can find like X number of warnings. Like get actions already check for them in newer PRs and things like that. Probably this is a driver which is not checked for quite some time in the main line. So I figure out, so this is a driver which I can contribute now. So with a specific exception like the indentation is wrong. So I wanted to fix that and quickly show how you can fix it. Say I go to specific line number 32 and I say this is a space. Like it must be tab whenever it's possible. So I change this tab, I mean space into tabs. Oh, that's it. Like that's a change you can make and contribute back just a second. And then get if, you know what you have made as a change. So now you can make this change into a contribution back in here. So for now I have a branch which is basically based on, sorry, the Git remote from Zephyr project. So I have a forked version which I will add into my own remote. Let's say, okay. And then I fetch for that branch remote. Okay, let's see if it works. I'm not sure. Okay, it works. Now I have this change here but I wanted to create a branch because you cannot push changes into a main branch. So it is merged back into main branch after you merge this PR into this way. So then like you check out a new branch or create a new branch called let's say fix, check patch DHT or something like that. And then you have your changes here. Then I say, okay, now I have made the changes. I wanted to commit it back. So what I can commute, I mean like this is a commit message probably people coming from a Git world can do. Say, if you are a first time contributor, you must be cautious in terms of typing this, like say, what is your commit message? Like the first liner and then like the message itself, like what it really does. You cannot be doing like, okay, I'm happy to contribute. No, that's not technically allowed. So you can, let's say, oh, sorry, let's say sensor, that's the subsystem or driver, which I have it. DHT fix code styling. And then you say fix code indentation. Sorry, yeah, but like I haven't committed it yet. So I will do a commit. Let's say I created the commit now. Let's say scripts, check page, that's a good point. Thank you. And then let's say Git, which commit, that's the head basically, I check for it now. So technically, okay, so now I have this branch and you can also do Git format. Let's say file, I'm not sure if it's, okay. There is a couple of other issues as well, like let's for now ignore them. So like I fixed this particular changes and then I have a branch changes in my branch. So I push this branch. Okay, so now it's automatically pops in a way that like I can go ahead and open a PR, but even if you don't see such link, you can come to here and then select the respective forked version and then you can go ahead and create this PR. So once you click the PR, I mean, let's say there are what other options you have, like when you have a large set of changes, something like you wanted to create a new feature or new subsystem or new RFC related things. It makes a lot of sense also, you can create add up a tag called RFC in here in top of your title or you can create a draft. And then like you can discuss with the maintenance and developers and like, okay, align with them before going into the final merge of the main branch. So couple of things here as a single line up. So like here when I say summary, you can cross-compact this with your Git send email, like say when you send a last set of patch series like say 15 or 20 patch series for your last set of things in terms of Linux, you say hyphen hyphen summary and give a notes say, okay, this is what the feature does and this is what I observed and this is what implemented. This is why I implemented. So you don't need to like say, explain what in a detail because that's a good code says, like, but then you have to say why you have done this way, like why you have chosen this particular approach instead of maybe a different approach will say a buffer or something like that. So those part can be explained in hyphen hyphen summary when it comes to Git send email, but similarly you can do the same thing in this particular text. And then like, like create pull request, but I'm not going to create it immediately now. So, but then like back into our flow of slides. So I forked it, cloned it or I just added the remote, created a new branch, added a set of commits, which I imagine like, okay, this is all the changes which I love to do it. So added a set of commits, now I created the PR. Now it goes to the discussion, as you can already see here, the respective maintainer is already assigned by the Zephyr bot and probably you, if you wanted to add people which you already discussed about this particular feature and you can speak about speaking with a respective maintenance like respective subsystems and then like you can speak about them. So you can think about like say, there is a script, yeah, get maintenance PR. So if you run this particular script, you can know who is the maintainer and then like the email address of it. So it's the same thing which is coming from the Linux world as well. There's an amount of contribution depends on the amount of contribution and things like that. So then you speak with the maintainer, merge align, resolve the conversation and things like that. So that's the whole flow as I can say, but like I'm gonna repeat things quickly as possible here before the time runs out. So we have one thing in common everywhere. Like you must do only one thing. Let's say in that particular patch which I created, if I wanted to add a new set of a variable to a structure, like you can get a new sensor value from a sensor and then like do processing, that's completely not related to what you do as a fixed alignment thing. So you must do only one thing in a space we commit and that particular commit should be compilable and testable. In a way like say I do as an independent developer, I do testing and development for a different purpose and then like when your commit comes into your place, then like I feel something is broken in my hardware, but it is not broken in your end, even though we use the same hardware, same SOC, same PCB whatsoever, but I wanted to figure out what exactly going on. Like I use GitPiSec most likely for figuring out, let's say 3.0 version of the Zephyr works for me, but then 3.1 breaks. So then like I use GitPiSec between them and figure out which one is the one. So when GitPiSec goes in there, I will compile each and every branch. So I mean every commit, sorry. So in that it makes painful when your commit breaks the compilation system. So you have to make sure that every commit of yours is compilable and testable. So there is also good commit and bad commit message. As I said before, you have to explain at least the minimalistic sentence like say subsystem what you have done, what exactly this does. So unlike why you've done this way. So specifically to speak about, okay this is a good commit. So you cannot just say like fixed code styling and push this commit. So the developer or the maintainer doesn't have any clue what you have fixed. Then you have to explain the based on the explanation then you have, you can know that like, okay, that's how it works. Okay, so that's about good commit and bad commit. I mean like people coming from the Linux world probably already know about it. So and this branches which were created. So the commits in this branch needs to be linear or relevant. Let's say the same terminology used in the other presentation. Let's say linear, linear meaning you cannot have a mergeable branch and you can add merge commits on top of it. That won't work in Zephyr. Basically in a way you need, your change set in your branch should be clean and it should be rebased to the current main branch. So when the maintainer accepts this and merges this back into the actual main branch, there shouldn't be any, let's say additional merge commits which you can bring in from different branch or something like that. The change set should be clean in a way that like linear, only your commits should be there, such a way. That's what I mentioned about and as I said mentioned about like, reviewers will be autosigned, you can discuss with people in Discord and okay, respect, you can ask for reviews. And yeah, this is one, minor exceptions compared to the, a few minor exceptions compared to the code staining when it comes to writing it. So you need, probably you need like, I mean the main exception here is like, you have braces in every block. I mean, okay, that's how it is. So if else and every block, even if it was a single liner, you need the block statements. So apart from this, it's most exactly same as like, the Linux kernel coding linelands. So if you come from there, you already are like, okay, with what is going on with the code staining process. So whenever you wanted to add a new external SOC and then like you wanted to add the hall layer for that one, so you might be, you must be considering with compatibility for this particular addition. Say, if I wanted to bring in a new JSNC implementation, for example, let's say I wanted to use JSON-C as a library, libJSNC, because I don't feel the implementation in JSON, JSON library within the Zephyr is not good enough for my usage in application development. So I bring in JSON-C, but then like it is nowhere possible to contribute it back into Zephyr because like that is completely GPL v3, which is completely polluting the license. You have to check for the license compatibility with Apache 2.0 and it's the community for the external hall layers. You have to speak with the maintenance and then like align with them. You can already get it said that, check the documentation and compatibility to figure out what can be contributed or what cannot be contributed. Probably you may need to reinvent something, something like Modbus, wherein like it is from a different stack, but even though libmodbus is available, which is completely different license like GPL v3, we have a dedicated implementation for Modbus. So something like this. So as we saw, like you have to run like check patch styling, C-lang formats and okay, so you have to run these checks during your compilation before pushing into your contribution, but also the GitHub actions does all these operations and give you an error saying, okay, you missed this. So probably you gave a sign off, but it is not a full name or you missed certain criteria in terms of your patches. So those part will be covered by actions as well. It makes a lot of sense. You can run them into your local branch before even pushing them to the main branch or before even opening the PR. So, and basically for the review process, as in any open source, you must be super patient. So that's the only rule, okay? You cannot like go and let's say ping, ping, ping, ping every day and ask for the review or ask for the merchant. That doesn't make sense because the maintenance will be busy. They have their own job. They have their own activities going on and they've been dealing with N number of other PRs and so on. You cannot ping them every. What makes perfect sense? I would say from Linux world, you can copy the same thing. Like you can ping every two weeks, maybe 15 days or 20 days. Then like if there is no response, like say no review response, there is no activities on going particular PR. Then probably you can make sense to 15, 20 days is a perfect sense in my opinion. So that's the thing about getting the review process. So that's the patience part. And then like in terms of getting your patches merged, you get the acknowledgement, let's say from the maintainer or so. Basically in kernel, you say act signed off by the maintainer. Whereas in GitHub, you say approved, then it's okay. It makes like, if your changes are like in architectural level, SOC level, then it makes sense to have, wait for like three or four acknowledgments. Then it is, if it is minor, something like this fixed styling, it makes sense to get two approval, then it can be merged into the main branch. So this is one difference which I felt as well. So Zephyr, wherein the developer, you develop something, push into the maintainer, and then the maintainer set of maintainers will review it. And then once all get approved, then you can go into the main branch. Where in the Linux or Uboot world, you have a chain of maintainers, let's say developers gives to the maintainer, then gives to the maintainers next tree, and then finally land into Linus tree. So that's how like it's a chain of approvals or chain of branches it will be going into that. It's not like IO branches directly going into Linus tree. It's basically go into directory and then like goes into Linus tree. So that's a hierarchy difference in terms of merging the final thing. So maybe if likely we may run out into time, so you can check in this release cycle when you wanted to develop a product or software product or hardware product in terms of using Zephyr for the product. So you have release cycles and then RC for features, feature freeze and so on. And also we have LTS release in Zephyr. So it will be folk like 1.7 was the previous release LTS. Now it's 2.7. You can use them for long-term support in your product and then like you can migrate from 1.7, 2.7 and another LTS going on further. So this I think we spoke a little detail, but okay, so speaking this in detail might run out of time before speaking the most important differences here. So if you need improvements, need help, then it makes sense to create issues here in GitHub. And then like you have to provide when you say bug report, I say you have a segmentation fault or something, it makes sense to file all the log information and then you can file a bug report and then like you can ask the respective developer for reviewing those things. So also if you wanted a new feature, completely independent stuff, you wanted a new architecture support, you can discuss them. You can add these things and keep it active in a way like you can figure out in your particular development. So you need more help, then probably you can discuss with let's say in the discord, that's a prime activity, which is I mean prime discussion forum which is ongoing, but if you have a specific discussion, we can also have GitHub discussions. There is also mailing list or yeah, you can of course you can open issues and discuss about the details and issues as well. So this is one general difference which we already discussed in the previous slides when comparing with the Linux world. So there is one key factor which I want to say apart from all the remaining parts, you already know it. So the in Linux kernel world when you push it out, let's say for 20 commits or 15 commits based on a large set of changes. So which is based out of different maintenance in a different subsystem. And then like your commit will be merged by Rob for DTS binding and then like diversity changes and so on, but the actual IP block of the driver may not be merged by them. So that is possible. Let's say you have the changes of your DTS binding in Linux kernel 5.19 and then but the driver is actually going to be merged in 6.0 or 6.1. So that is possible. That's a partial merging part, but that is not possible in my opinion in terms of the GitHub PR wherein you have to let's say pull everything together merge everything together. So apart from this, like you already see what is the difference. So you make sense to contribute. You have minor changes, large set of changes and you have a custom PCB based on your customers. And then it makes sense to contribute back to Zephyr mainline community even though if it's not an open source hardware or even though if it's not like a publicly community available hardware because when you migrate from one version of Zephyr or let's say 2.7 to 3.2 or something like that bumping a release would be super painful. Otherwise, if the board itself is not in the mainline. So you have to be keep maintaining them in your local if you keep this changes as an external board repository or driver repository. So you can convince with the various points with your customer as well as your reporting manager or so it makes a lot of sense to contribute back to Zephyr in a way. So as I mentioned about like say the presentation by Carlos and Marty and then like you can also find presentations in Zephyr developer summit about Twister and other important things like major things. Also the link which points to the contribution guideline of Zephyr itself. I think that's mostly it from my end and I'm not sure how many methods we left maybe three for questions. Yeah. Yeah, sure. Basically we rebase and remodify the commits. Let's say if you have a architectural change and SOC change within the same commit which makes no sense and like just an example and then the maintainer would say split this into architectural specific and SOC specific and then try to break it down. Then you split the commits, squash it and rebase it, yeah. So basically how this works is like say if you have a bug in 2.7 LTS release that's a long-term release for example and then like you have the main branch and if you find this bug both in the main and as well as 2.7, you fix this actual problem in main branch and back port this thing back to let's say you need this feature for LTS, tag this for LTS release and then back port this back to 2.7. So assume your change bug is already gone and fixed in a specific commit in the main branch and it's not tagged for back port specifically for this particular LTS then you can ask the maintainer on tag this particular commit for LTS and then it will be back ported to 2.7, like sorry, 1.7, I'm wrong, so 1, 2.7. So let's say we have a release like 2.7.10 and then it will be released for 2.7.11 then like back port patches like vulnerabilities and other fixes. I totally get it. But the point about bugs or fixes is let's say you're not asking for a completely new feature like memory management changes in architecture. Of course not, right? So you have a vulnerability or you have a minor patch fixing or let's say there is an exception in your segmentation or null pointer dereferencing which is missed in a specific branch LTS but it is fixed in the latest. That would ideally be a smaller changes, yeah. Sure, thank you. Sorry about that like the time's up and thank you so much for joining today and I will be around for questions if you have as well. Thank you.