 Welcome everybody, you know you coming in from lunch So I was going to give a little bit of time for people to trickle in. This is working with a Linux kernel In the Octo project So anybody's in the wrong session feel free I See a lot of familiar faces Been presenting for a little while so some of you already know me for those of you who don't a Little bit about me. It's in my vanity slide my bio So I've been working and embedded since 1996. I've been working specifically Professionally with Linux since 2006, but I started playing with Linux in 1999 To build myself a little NAT router for a DSL connection that was open to the world In the OSS world I am on the the board of the open embedded project I'm also a member emeritus of the Yachter project advisory board and happen to be part of the the technical steering committee for device tree dot org All which is to say I'm really cool, right? So the more enthusiastic you are the more enthusiastic I will be I tend to thrive very much with an interactive audience so All right So Here's kind of the basic outline We're gonna start with a little bit of project advertising I'm just gonna throw up a couple things about what's going on around the conference with the Octo project Offer a little disclaimer about what this? This presentation is intended to be and what it is intended not to be then I'm gonna dive right in with some basics and We'll get into more specifics So this is as much for people looking at the slides later as it is for here with Time remaining and hopefully with everything else working. Do I have a little pointer? We'll get to a live example As you all know a live example can many times go wrong and frequently does so if that doesn't work out Then we'll move on but everything's contained on my laptop So why don't we do a little bit of the advertising? This is a little you can actually see this placard You can actually see this and print form down in the Octo project booth this these are all sessions related to the Octo project including Thursday event which is kind of an extra event outside the conference This isn't I'm gonna upload my slides as soon as I done present. I'm done presenting so you can see this It's also available to you in the booth On Thursday, we have a Yachter project developer day. I will be taking a session there as well This is lifted straight from the URL down at the bottom The takeaway is that if you are looking for a way to accelerate Your knowledge for the Octo project. This is put in this is put on by the Octo project itself. It's off-site Happens to be at my former employer mentor graphics and We do still have some I think registration slots open so feel free to sign up We'd love to see people here or see me see people there If you really want to pick up some new knowledge and there's two tracks on that There's a beginner and there's also an advanced. So if you're already familiar with the basics, there's still value to be had there The Octo project booth Please go by let them scan your badge. This helps us Quite a quite a bit, but it also gives you an opportunity to talk to Developers and maintainers directly. We all are generally down there or congregating around there and can answer questions Or point you to people who can you can get more information about the sessions that I already threw up And of course you can get more information about the project. There's also some free stuff In fact, I don't know if I have it in my pocket or not The stickers and there's a little yachty fuzzy thing and a few other things and then also we're gonna be There's also gonna be a chance to win a copy of a book Which I reference here, but then I actually talk a little bit more about here This is the disclaimer. There's a lot to this topic, right? There's no way that I can cover everything related to kernel development and the reactor project and You know a single talk So what I'm gonna be trying to do is highlight some of the things that I think are important There's a lot of resources out there, and I'm trying to distinguish myself from them So if I am leaving things out that you find in those a lot of times that's on purpose I'm trying to just kind of give you what I felt was important for you as a takeaway in isolation And I also want to call out Scott for because you're sitting right in my eye line for you know Putting together some of the best project documentation that I've seen I'm very biased, but I really think that this community is extremely welcoming and extremely friendly So we love to see new people come in and we love to help new people coming in Would really want to see new people in new faces So with that said one of the other things I have to call out is the embedded Linux systems with the Octa project by Rudy This is a really really good book I have a copy of it here. This is the book that we will be giving out. I think we're doing one a day So really good book that covers in depth a lot of the ins and outs of working with the Octa project So with that under our belt away we go so For the kernel whenever you're doing development, you're gonna need some pretty basic things and I mean really basic You're gonna need kernel source and you're gonna need a kernel config All right In order to make it play nice inside the Octa project You're going to also need some metadata or a recipe now I'm assuming everybody in the room has at least passing familiarity with the rock the Octa project If you don't know everything up here, don't worry about it and also knows about kernel development Again, this is not trying to be an in-depth on either of those two topics We're trying to put things together. So for the purposes of our talk. We need to consider Different types of kernels and I don't mean arm versus x86 or things like that There's Linux Yachto kernels, which are kernels that work with a set of tooling and I will go into what that is in a minute There are what we would call traditional kernels Which are ones that in some cases pre-date or for various reasons just do not support that Yachto Linux Yachto tooling And then new and for many of you in the room the new kernels are going to be of the most interest It's how do I get a new kernel that I want to play with into the system? As I say here a lot of times this is from semis, but you got it from somewhere Usually it's in a version control like get but occasionally you just have a tar ball dumped on you There's no real specific tooling for those types of kernels or for the traditional one There's a there's general tooling that we will make use of So a little bit more about Linux Yachto kernels and in particular the the tooling involved with them The Octo project maintains several kernels in each release and Around those kernels as a set of tooling that helps making Helps make supporting multiple platforms with a single kernel a lot easier That's important because if that's not your use case. This might not be the best option for you Coming in green now we'll talk more about other recommendations in a sec One of the key benefits that you get from using these kernels is config management again. We're talking about across multiple different platforms we're talking across Many times tens of different types of devices, but you want a single kernel that you can rely on so managing all that configuration Information this becomes a lot easier Once you have this full scaffold built up for you I'm going to talk more about what a config fragment is They allow the in order to build on that point above where the configuration management The kernel configuration management. I should be careful Is that it's allowing you to break the kernel config into smaller pieces that you can apply across multiple configurations? So this is extremely valuable again when you have a lot of lots of different platforms I alluded to this already, but all of this is Done the tooling relies on the fact that you have a very specific set up of the kernel in a git repository And a set of metadata files in that same repository in an orphan branch I'm going to make you aware of this I'm not going to dive a lot into depth on on how this is done I'm going to say that it is done and it relies on this But what we're going to focus more on is how we use it This is really kind of the takeaway that I'd like to leave you with This is an extremely configurable and therefore very complex System to set up This consumes a couple of developers on the project Every cycle just to keep these things going forward so Setting it up is Time-intensive however using it is not and This is where I leave you with us So since the yachter project is actually maintaining several of these kernels for you if you can leverage them Then you get the benefit of already having all this stuff all the scaffolding built up And of course, that's also a reference model if you decide that you do need it I see you guys from Garmin. This is probably something that you're gonna want to look at the difference between the kernels they're really There isn't much difference per se It's just the way that the the kernel is structured in the git repository. So for each release that we go through There's a selection process by the kernel maintainers. Well, they will go and pull an LTS kernel LTSI kernel and Usually one other and you have to go and look at each release and the release notes It'll say which kernels are supported Obviously the well, I say obviously for those more familiar with the project one of the the primary validation targets that we use is QMU And so there are going to be things that are a little more specific to making that work right out of the box But for the most part they're it's like with any kernel tree, right? You're gonna have some stream of patches that might vary a little bit But we they try and stay really right on top of of mainline as much as possible So you'll see that the the upcoming release is Does do you know mark with a the? 415 okay, so Like I said, they try and stay pretty close up without Great question. Any other questions while we're at all right. You're starting to get sleepy again So I mentioned the different classes of kernels What about adding one that we just have a kernel tree? You know I get repository they want to do so The simplest approach for people coming in with a new kernel is just to simply take the traditional approach You're going to add in the kernel source and your doc config in this case. They're gonna be called def config directly into the build via recipe There's a good rely heavily on a kernel BB class that BB class takes care of most of the the Heavy lifting if you will of setting up the cross it takes care of all of the heavy lifting of Making sure that your cross-compile environment is good to go There's a few things though that you need to to do and I actually took this example from From meta ti Dennis you in here So it was it was a really good example of how we do traditional Kernels and I trimmed out a whole bunch of stuff that wasn't really relevant for our talk So there's a lot more to this and there's include files and other things in here But one of the main things I wanted to point out was that you have this nice inherent kernel that directive inside this recipe is Going to activate almost everything that you need You'll also notice that this source. You are I Is just basically pointing to in this case the ti Linux Get tree so you've got a repository out there It's got your kernel in it you point it to it and then you include in the file Sub-directory your config so if you're starting from a baseline config that you found in the tree you copy it to there You push all this in and then away you go So I'm gonna pause for a minute see if anybody has any questions on this It seems pretty straightforward, right? okay, so I'm As an architect I find myself many times having to think about what is this really boiled down to or boiled up to? Depending on how you want to look at it So what are the really basic steps that we need to do and how is this different from normal kernel development? So normal normal kernel development you've got your tree you make your changes you compile you throw it on a target Lather rinse repeat. So what are we doing differently now? really the main thing is we need to add this kernel into our build environment we need to add this into the cross-compile environment make sure that all of the the Toolchain pieces line up and all of the the different optimization flags line up so that When at the end of the day our kernel compiles into this environment cleanly So the first step then is to do just that we're gonna add it in via that recipe example that I showed you or if you're lucky You already have one that's out there into the build environment Next thing you're gonna do is just like you would before you're gonna verify your build you're going to Make sure that it actually runs on your target if it doesn't then you're gonna go back and you're gonna start making changes You're gonna make changes both to the source and to the kernel configuration After you've made those changes you're gonna need to capture them That's it Right easy. We're done Right. No, okay still sleeping So the main thing is how do we capture those changes, right? You're the fundamentally the steps aren't that hard, but the devil's always in the details. So capturing these changes It's gonna influence the way you construct that recipe. I gave you the simple version which had just the git repository It also will the The way you capture these changes influence the recipe and of course the recipe By it by Correlation is also going to influence how you capture these changes. I know it's very to top it's a circular But the idea is that if you have a tar ball You're gonna do things differently than if you have a VCS if you are Working against a known baseline and trying to modify it. You're gonna do things a little bit differently so This is a little bit of a Little bit longer than I thought it was on when I wrote it, but you know when you're One of the key points about this and I already alluded to it is where you want to capture your changes As with all recipes in the Octa project You have the opportunity to store those changes as patches Or you can also store them as a change in your version control system Again where you derive your kernel from as far as a baseline is going to drive a lot of times. What's the easiest model for you? Most cases you're going to use gets This same process is going to apply both to the kernel configuration and also to things like the the device tree Which I really don't refer to in any other place on here Personally I find that once you get past a handful of patches In your recipe and in terms of your your layer it becomes a Bit cumbersome to Continue to modify that So I tend to strongly prefer git and then when I get later on I'll show you the particular workflow that That I generally adopt where possible So we're gonna take a little bit of a pause in the middle of this to talk about some specific capabilities and yes, sir Why would you run to I'm generally running just one yes There's actually a tool that I'm going to talk about called dev tool which does some of that similar type of thing for you There there's a tool that we have in the project that I will talk about in a later slide called dev tool That kind of helps automate some of that process for you Yeah We'll dive into that more again. I'm having to hit things at a very high level so certainly come afterwards and we can Okay Where was I alright so you know again, this is very high level. This is very generic right you're talking about Some things that are just absolutely You know run of them run of the middle type of things, but they do have sort of long-lasting impact So if you start using you know git to capture your patches then And what I've found is that that makes it a lot easier for instance to Diff patches are fine when a particular patch has has gone wrong Using bisect and things like that you lose some of that capability when you're using just raw patches stored in the layers So that's part of the reason why I look at that and prefer it So getting into a little bit of bit bake and this this goes to ways that we capture those changes Keep an eye on time here So This is I know this is probably unreadable for most of you all I did was a list tasks here This is the level of the the kernel tasks. So again, this is more for reference if you're looking at the slides later I'm going to highlight a couple of them that are very valuable One of them is the wrapper task that is around the menu config So if you've done any kernel development, then you you're familiar with make menu config In order to execute in the bit bake environment, there is a bit bake minus C menu config of your kernel This is going to pop open a UI that you can use to manually edit different options and select them There are however some caveats to this Yeah, I already covered that Because of the way that The execution occurs in the the octa project environment you have to make sure that a configuration already exists so if you just do a If you go and you do a creation of a new environment for using the oe in its script and you do a bit bake Minus the menu config virtual kernel it will fail You have to execute the configuration first a simple way to do it I would just tell it to build until it was complete But an alternative is also to use The kernel config me command over here having a hard time seeing this So this will basically drive the process through to the point where it's completed the configuration So that then the next step would be to issue a menu config One of the other things to be aware of is that just like the command functions in your tree On without the octa project being involved at all. It's modifying the dock config in that kernel source tree Well, this is slightly different when you're trying to build this inside the octa project so it's building it inside or it's modifying it directly inside the working directory for the project and That means that you are subject to The whims if you will and it's not really Whimsical, but there there's certain steps that you might take in terms of modifying recipes and things like this That would blow away that configuration So if you've spent a whole lot of time very carefully selecting Options in your menu config and you've got it just the way you want it and everything else and you think okay Well, I'm gonna clean everything and I'm gonna I'm gonna start over make sure everything looks good Don't do that I think everybody at least has done that once and has lived to regret this because then you go oh Because it blows away that that working directory and that config is now gone So make sure that you're gonna capture those changes There's ways that you can do that That involve the next command, but I mean Bare minimum you can just copy that that file out of the work directory So another important one, oh, sorry What I put up here Oh One other one other point to this so let's say that you are actively modifying your your menu your config via menu config and you do not want to Invalidate previous steps, but you do want to force it to do a compile Because it's the tool changed it directly in the tree. It's not gonna necessarily do a recompile so you use this minus C which quite honestly I used to use I just use minus F which is a force I didn't use minus C and Has some other side effects. So this one is a better way to do it Rudy's book actually when I was doing some prep work for this was where I found this so That basically it invalidates the particular estate cache For that task and then forces that task to rerun So it's a very valuable way to tell it. I just want you to recompile and see if the compile actually works So little little time saver there in terms of if you don't do this and you do a minus C compile It will just use what was in shared state and say, yeah, I'm good and Move on So this helps ensure that you you get what you actually changed. I'm sorry. Yes This is one of the dangers of spending too much time with something It's yes, it's very obvious to me that that's a capital C versus a lowercase C and those are different I think I actually put it in another slide. Yeah, I did I put it there Because I thought about it. So yeah, I mean basically the lowercase C Is is where you're gonna see different. So I have it in red Thanks for the question Let's look at one other one here. So again, there's another script inside the kernel called diff config Actually, it seemed to call that was something that Tim bird did It does a nice comparison of a sorted Kernel configuration file and then generates just just what it says the difference between those So bit bait gives you a way to run that When it runs successfully, it's gonna actually just throw out a little a Little file path that it has that config file config fragment. That's what this is gonna be That You can go and look at but that's also in that work directory. So again, you can lose this if you're not careful Once that fragment is generated Yeah, there should be yeah, if you just execute that it'll take Yeah, I need to correct that But again, it wraps the kernel script of the same name It is generating that that delta against a baseline So this is actually really part of the reason why the menu config Needs to run and also why that are excuse me Why you need to run that kernel config me beforehand because it's part of the process of generating this baseline and Then it uses that baseline to compare against and for for any changes that you may have made and When I get to the live demo, I can show you when that gets created Um Here's some considerations Or excuse me the same considerations are gonna apply as far as the the menu config because as I said that Fragment gets dumped into your work directory You have to worry about whether or not your work directory is gonna get removed Still with me. Everybody's still awake All right, cool so Creating and integrating those changes are the basic developer workflow, right? We've gone through the that basic first step, right? So now we want to be able to turn that crank we want to make the changes to Configuration of our kernel we want to make source changes We want to be able to have those flow back into our build in a clean way Yeah, so When you start from an existing kernel recipe great Seriously, you're almost done one of the reasons why the yako project exists is to make it as turnkey as possible So for the ones that are currently in the yako project you already have a recipe. It's already integrated into the build system You're most of the way home. You you now can focus a little bit more on your changes in the kernel In order to modify it one without modifying it directly as the gentleman in the back was saying about You know, you're gonna push to kernel a lot of word. Well, I'm not gonna push to kernel or somebody else might You general process you're gonna go and create a layer. I Suggest using the yako layer Tool which is part of the the yako project. There's a yako layer create. It'll create a skeleton for you You know, it's funny because I'm getting told that that was actually removed in the latest release. Damn it. I Have a caveat at the end of this which says the tools are constantly changing. So cool I'll go and strike that This is a this was just a way to copy out a skeleton file anyway So you can find that and we haven't removed the skeleton files. Have I haven't looked in the last you don't know. All right anyway So the at this point if you are if your kernel supports the octo kernel tools remember I said there was two different classes. There's the ones that Currently support the yako tools and then there's ones that are still we carry them in the layers They're they're available to you, but they're considered traditional and they don't use the octo layer tools So for the ones that fall into that former class You can use that diff config command in the menu config to manually create changes and generate config fragments in order to put them into your layer and I don't think I actually said anything about how to do that. Damn it So basically those dot CFG files you can add to your source URI Sorry, I need it. I need to add that in However, if your kernel does not support the octo kernel tools then really you can still use menu config But the your your config file is sitting in the tree. So at this point You're gonna want to copy that out and if you go if you think about that recipe example that I gave you a few minutes ago That's that deaf config. So you'll copy that back to your layer And then check that in and then away you go so That's that's the basic part of it and then for your actual patches as opposed to the the config portion Again, there's you you have two different major Directions, it's basically add them in as patches or add them in Into your version control It is not there is a way to do that But I didn't go into that here and it's a little more involved. It's honestly something that I have never done So there's plenty of people at the project who can talk a little bit more about what all is involved in doing that It's bit big clear, okay Yeah It's a moving target So again the last I think point that I put on this and I'll say it now and then I'll say it again later is keep up with it I mean pay attention to what's going on clearly it can slip by you So this one's probably more the way that most people think of it. I've got a new kernel I want to actually add into my my tree. I What do I do as far as? Getting that in there. It's really not that bad. So I already talked about that that skeleton recipe If you add that kernel recipe to the build system see that one above Then you've got it integrated into your build system, right? You want to make sure this this is one important step here again. This has bitten me before too You want to make sure that in your local.com you're setting your preferred provider Or maybe in your machine comp, but this is the most straightforward way To set, you know, your preferred provider is now that new kernel And that's whatever that recipe is that you created here Going from there You know now you've got it integrated into the build system and then pretty much you go back to the previous slide as far as the steps are concerned You can use diff config if it's a yachto tool if it supports the yachto tools yachto kernel tools or You know you can just copy your your config in I think the simplest one is just to copy your your config into def config And away you go and then patches the same way So it's it becomes the same process still with me Cool All right, so creating kernel patches, you know this I really kind of struggled on this slide more than almost any other And it's because there's so many different ways You know use your favorite editor we could get into vi and emacs wars if we wanted to But you know the idea is that you've got a Tree on your system and you can create patches of those so One way to do it and I don't recommend this is you can go and work directly in the work directory that we spoke of before You can go and make changes there You know, this is easy to get to by using that dev shell the dev shell command And for a quick, you know Check of something that's probably more than sufficient, but you do you are now again at the mercy of that that work directory going away It is nice. However, and that you can drop immediately in you can execute for instance and then make menu config and it'll run You can do most of the the operations that you would expect to do a normal kernel development So it's very low touch, but you don't have a whole lot of safeguards But it can work If you are working against a tar ball you will have essentially no version control So generating your patches will also be a real pain if you are working against a get tree Then you at least have get to do diffs against But there's a better way I Think I've already covered that point you can lose work You can also work, you know with your with your source on another tree I don't know anybody doing does this with a tar ball type of idea But most of the time that's going to be with get I suppose you could But that basically removes the possibility that work directory That source directory gets removed out from underneath you Again, if you're using a version control system, please leave You know you're not going to lose it from accidentally because of a bit big But this can also be a little bit cumbersome because now you're kind of working outside of the octa projects build system and Which you know All of the the laring and capability that you have there is sort of this separate piece And yeah, I know a lot of developers who do this though when they're really kind of spinning tight on trying to build a particular You know kernel or they're working to get a kernel working Functional on a on a piece of hardware. So this is this is fine Remember when we go back to those basic steps, it was added into your to the build system Then you're going to lather once repeat in terms of the configure it make modifications of source and integrate it back in Well, if you're testing all of this stuff outside of that process Throwing it directly on a hardware. This may make this may be your best option to start with And as I said about the vcs system You can generate patches using some like it format if you really want to That is a typo That should be a pain So sinking patches can be a pain Uh in terms of keeping things up to date cool That was there just for humor then there's what I call a dev tool workflow And there's probably some better term scott. Do we have a official term for this process? Yeah For kernel, I didn't think so Dev to preferred So dev tool I'm curious how many people know about what dev tool is That's good. That's not too bad. Um, I'm going to talk a little bit about it for those who don't It is a command line tool that how am I doing time-wise? I don't know. Anyway, I'll speed up a little bit It's a command line tool that's going to make it easier for you to do some of this quick turnaround for recipes It's not specific to the kernel It's really there to do similar to what the gentleman in the back was discussing about creating a get tree Not a get tree a get repo that it's going to check out your source into and then you can easily identify what has changed From the baseline that it started with so this Tries to bring that faster development cycle right into the process for For the build It creates a temporary workspace layer And it adds it automatically into your bblayers.conf This is some of the mechanics of how it accomplishes what it is that it we're trying to do You can work against the live source you can generate the patches using the the get format patch or There it will actually collect patches dev tool is smart enough to when you're ready It will actually collect those patches and push them up to Another layer, but it basically makes that process a lot a lot easier I'm not going to go into a lot more depth on this. I will Highlight one command Which I think is up next So as I said it works well with a kernel and once you have that initial recipe in place for your new kernel Or if you had one that you and you were inheriting from It's a great way to just simply set up a workspace in that tree that you can begin to make modifications on directly And do so in a knowing that you can immediately kick off the build Whenever you have a change set that you're ready to look at and see if it at least compiles It also dev tool will help you push Some packages. I don't think it really works well for the kernel for this Down to the target. I haven't done that. I usually load it differently NFS or something But this is the command that will kind of kick this off So dev tool modify virtual kernel Or the name of your specific kernel Once again inside the bitbake environment is going to one create that workspace if it doesn't already exist It will insert that that workspace layer into the bblayers.conf It will check out the source One other interesting thing that I hadn't noticed until I really started looking closely at it is that will also run that kernel config me command and in the live The live demo we can actually see that occur So capturing those kernel patches then I I've hit on this a couple a couple times It's because the source that you use a lot of times is going to influence the way that it's easiest for you to capture changes back to it So And I'm repeating my own slides here So one of the general patterns that I have found is that if your kernel pulls a source tarball Then it's going to be generally easiest for you to collect patches against that tarball That isn't always the case There's sort of a another approach in which you can take that tarball put it into git and then Rewrite the recipe in your bb append to go and pull from git But that's a little bit more advanced It's not really that much harder, but it's just an alternative Really, I'm happiest when it pulls against a version control system because then you're able to create the patches directly And then you don't have to worry about updating the recipe to include source patches every time I have had more than one occasion in which I was adding several patches and I missed one and things really get squirrely and You have to go back and then manually audit the list and the recipe So as I said when you get past a handful really strongly consider using git version control to make this a lot easier This is not this is not really that hard, right? I mean, this is not really all that groundbreaking That's why I kept trying to boil it down to those basic steps You want to get this so that it builds in in the yachter project, but then you want to kind of let it get out of your way So that that is really The the goal for me Um is to make this stuff kind of get out of my way. So let's see if I have time here. I'm going to Pull up an example Hopefully you guys are seeing that so I'm gonna make sure I cleaned up first um Okay, so this is telling me that I didn't have my workspace left behind Uh, yeah, sure. Sorry It's like my eyes are that much better How's that? Is that better? All right, so I wrapped this up just so that I wouldn't type of things but all this is doing is the the dev tool modify um This is you can see it going through the steps Where this is running in a virtual box Vm on this laptop. It's in a boon tube box And there's a couple wrappers in place for the shells, but Um, it's going to go out there. It's going to do the kernel check out as I said it created the the workspace layer Um, and injected it uh into the bv layers um At least the initial time that I ran this I don't remember if I cleared it before I came Uh, and then it's going to take a little bit of time to do the kernel check out and it's running through now This one is a Linux yachto kernel. So, uh, it runs on qmu x86 um That was just for simplicity. Uh, the same step works for for any other kind of kernel, uh, that you want to look at And that's going to take a sec to complete Any questions Do you guys remember when dev tool initially hit? I mean, it's been a while. It's been a long while relatively speaking For anybody coming to it knew it's it's there and I I wouldn't worry about it. There are going to be subtle changes. Uh, clearly, you know, there's Some things get renamed some options changed and the like But uh, yeah, I mean dev tool is there So and there is a session on dev tool at the the yachto project Dev day as well Since 2014. So yeah, I mean that's like ancient by open source project standards um, so And it continues to improve um You know, I mentioned before as we're this is where I kind of do my song and dance while we're waiting for it to run um, that there was a specific setup, uh, that the the Linux yachto tooling relied on In order to do some of the magic and what you can see here Uh, is not the config me one to see this kernel metadata Uh task there that's related to the yachto tooling So that takes a little bit of time while it goes and it actually I skimmed it very fast, but it's taking all of these different config fragments There's logic applied to them in terms of machines that they apply to and they don't and it consolidates all that And then generates a full blown, uh, config for the kernel Okay, so now we're done at this point. I now have a workspace Um, it's not the most stable platform. Um, so if I look in the workspace sources I've got a Linux yachto And you'll notice Um, that there is a config in there. It's all ready to go If I were to issue a build right now, uh, it will go through the the complete Build steps and generated here and in the interest of time Let's take a look at, uh, the config. Well, actually, let's let's do this first. Um We're gonna run, uh qm you No, we're not Oh, it helps if you build it first I still have my own petard All right, we'll let it run for a second Since I've done this build before It shouldn't take too too long after it gets past that config stage um So what the example I'm going to do here is I'm going to basically run through and do the, uh The menu config I'm going to alter it Uh, and then I'm going to verify that that change actually ended up in the in the live target Which is under run qm you so this is running. Are there any other questions? Yes, I'm sorry so there are limitations in terms of Using dev tool, but they continue to be removed with each iteration. So, um, I Generally use this with the the def config file because that's the simplest but Yes, you're right behind this the question was um dev tool is using external source behind the scenes that it That is a true statement that is A way to use an external source tree And there are occasionally issues with that I've seen with trying to use dot cfg files Um, but if you force it to go through into the config me stage Again, uh, I that works for me So but normally I'm using in the model where I've got the I don't use the the linux Yachto kernels as much as I'd like I end up using an external Kernel that I have to bring in so then I just have a def config and I manually copy it over Okay So this is going to take a minute while it compiles Didn't think that part through Any other questions while we're waiting on that Mm-hmm Right, right. So the question was if uh, you are using config fragments Can you go and look at what it generates? And copy that out and use in the answer is yes So what I have done personally is I I use git and add a remote and then I push From within the workspace So then I can I it's checked out from from an upstream git But since it's it's replacing git internally in the workspace this gets into the details of the way dev tool works It's it's not really connecting the dots there. So you can go into the workspace add add the remote laptops getting sleepy And you can go into the workspace and add a remote and then push directly So that way you're getting the benefit of using the version control system to capture patches Right, which is the case in most cases, right? If you've got in Larger than one group you're probably not Working directly against kernel.org So if you've got a version control system, you're yeah, sorry, I'm just You're absolutely right the the consequences then yeah, the recipe is generally not going to pull against kernel.org So um, and that's sort of an important point that I kind of glossed past in your recipe You wouldn't point it upstream to kernel.org because you're not going to be able to be on trip it You know the the meta ti layer is pointing to the the linux ti kernel You're not going to push against that. So again the implicit step there is that you're going to create some version control system Inside some place that you can access and you use that to to capture your changes So yeah, it's it's a it's a good question. Yes, sir. You want to stand up and smile? So I mentioned that I previously worked for mentor graphics So osvs are going to use this more than than the average or larger organizations are going to Um, you know, it depends on the specific Semi whether or not they they provided or not. Um, so I make a comment in fact While we're waiting for this to compile. Why don't I go back to the slide here? Um, Let's see if I can Jump to the right spot Um You know your your your question kind of hits very much with the first point there Most developers are going to start with a kernel that's coming from a semi or a board manufacturer, right? In that case My advice is take the path of least resistance, right? If they have a kernel that supports the octa kernel tooling Then great embrace it and use code fragments and use The the the normal path that you would take to generate Kernel patches But for other ones use that basic template Man, I have too many typos in this So, uh to to facilitate, you know Bring it into the build system, but then you're kind of working as much as possible In this tight loop outside, which is how dev tool tends to kind of bridge things um To my to the point about the use of the yachter tools If like the garmin guys in the back you have a lot a lot of platforms that you have to maintain a single Base on this is where you're going to really derive a lot of benefit from the from the yachter kernel tooling So invest the time upfront You got to go look at what the structure is that you need to have and get and there's a great There's a great kernel development guide That scott has worked, you know on that helps you to make sure and bring Bring that in so spend the time to do that I find working against, you know a git repository and using dev tool I tend to minimize my pain That's my pain. So, you know, you're going to have to do what is going to work best in your particular environment um There's my point at the bottom which is you know the tooling continues to improve in every release So make sure that you keep up with it Or you might end up with a on your face, you know in the final line We're already into questions and I think I'm running low on time. How much time do I have? Am I out? Whoops. Okay. Thank you