 So I am Kim Raj. I work at Open Embedded and for daytime job I work at Juliper. So I will be talking about eGlypsy making it configurable. So there are some cool features that's there in eGlypsy that probably many of us know and so today I'm going to talk about the configurability of eGlypsy. So what is eGlypsy? It's a variant of GNU-C library especially aimed at embedded systems. It was launched about six years ago. The main purpose of it was to get improvements into embedded systems and back then Glypsy was more and more targeted towards desktop-based systems and there were improvements that could be done which were specific to embedded systems were not that interesting for desktop systems. So the main focus was of course the features that would make sense into the embedded systems. So as you can see binary compatible with GNU-C library so it would always be in sync with the upstream GNU-C library. It mirrored every day and it follows the least schedule of Glypsy completely. So it's an add-on on top of existing Glypsy. No features are removed from upstream Glypsy and many of the features that are proposed on eGlypsy which are essentially common for Glypsy are redirected to appropriate Glypsy mailing lists all the time. So it's an add-on as I said earlier just makes it easy to get Glypsy into the embedded systems. So what are its goals? One of the goal was to reduce the size and so I'll talk about. So the whole configuration mechanisms that were put in place were mainly to do the size management where the fully blown Glypsy is quite big. And the other fundamental issue was cross compilation. So most of the embedded systems are cross-compiling build systems and there were improvements or fixes that always were done on top of Glypsy and it was thought that Glypsy will consume them and it would make it more cross-compiler friendly if you will. And so for that matter if you go to eGlypsy sites then there are very nice documents on how to cross-compile it and how to actually run eGlypsy tests in cross environments. So it has very extensive and very nice documentation on that and it has been adopted in major distributions especially Debian thereby flows into Ubuntu, Open Embedded flows into Yachto and others and Gen2 also has a port of eGlypsy if you want. So website is eGlypsy.org and it hosts all the information about it, all the releases and information about mailing list and SCM and everything. So what does it have for managing the configurations? When the configuration management was introduced into it it was inspired by key config but wasn't key config. So you can say it's like a homegrown mechanism for handling the configurations. So in eGlypsy's wall they are called option groups. The option groups are key config or configuration in general is can be a blessing and it can be a BMS. So it has to be designed very carefully what parts of your projects you want to configure and it was decided that based on the project specifications the categorization of various option groups will be done and it has the same syntax very similar to Kernel's key config and as we all know key config is also part of other projects like busybox and eGlypsy. So it was it is pretty similar to that one but not exactly same. There has been some work I'll mention that later to bring real key config into eGlypsy. So that's how the configurations are maintained and there is a whole list of option groups which are actually documented in the source code I've given the name the options group dot def it documents all the possible option groups that are right now available. It's being modularized even more but you know as people come with various option sets they get added and so it has grown over a period of time. Essentially as of today what we have is for example networking you can disable it if you want it's as an it's a option group available. Similarly Libam the mat library is optional you can remove it if you want. Other options are essentially locales if you don't want them and then Glypsy uses a lot of inlining so you know it's important for code size sometimes and there is an option to disable really big macros so that's how eGlypsy does inlining it defines macros and then includes them in the source code. So if we disable that option then all the big macros are disabled and they are converted into function calls. So these are kind of and then there is the catalog handling routines they are also optional. Likewise there has been many divisions done at the feature level in the option groups. The default options are stored in option groups dot default so when you're building this is the one that's read first and the default is to enable all the groups which means no change from status code. So if you don't do anything it builds the same set that you would build without keeping fake being part of it. So other thing that's very important is that it only enables the features or disables them essentially it doesn't modify some functionality so for example it wouldn't go and say okay you know there are redundant print apps I'll just remove them so it either enables so like Libam for example it will either enable it or it will disable it fully. The second thing is the consistency is that default is to switch everything on so there is no like a carved out combination that you would use by default so that simplifies the configuration management and essentially it helps in debugging so for example you have a bug right you tweak the configuration somewhere and then you have the issue and you can go back to the default and then start disabling one option after another the ones that you have disabled and thereby you can get to the bottom line of the issue. So it has been tried that we can keep it simple because if you look at for example Usylipsy it has a huge set of K config and there are architecture specific options so if you're compiling for ARM it means something else if you compile for MIPS it means totally something different and buffer sizes vary and you know it's it's it's quite a mess and as a result you end up with like you know this is a well-known working set of configuration set and you live with that. Usylipsy has tried to use the simpler versions to manage the configurations. Moving forward so I have a combination of options this is using Yocto. Essentially I did a few measurements and so there is a versions of it's called Pocky Tiny which basically uses reduced set of functionality from G-Lipsy and so I could compare a fully blown E-G-Lipsy the Lipsy part of it for ARM for example is 1.2 megabytes in size and it reduces down to 830 kilobytes. Similarly the LD.so reduces down because LD.so has a lot of debugging options that are part of it and there are options in the key config if you go through that you can disable those which essentially reduces the size but it also removes the functionality so you know you cannot do runtime LD debug and stuff like that so you know it's configurable at a cost. Similarly Libem reduced because Libem has conversion routines from float to long double and double and sometimes if accuracy is not something that's important to you and you can live with you know less accuracy many times in embedded systems you know you really don't care about the transcendal functions but if you do and you can live with like say you know single precision then there are options in Libem that you can disable those routines which do the single float conversion to long double and back and forth so essentially you get little less accurate results in a floating point calculations but the size reduces down half the reduce is quite a bit so so likewise there are main options for the library the C library itself and then then if you disable the network then all the Libresolve and and friends they get disabled similarly there are options to disable crypto if you don't need it you can disable crypto for example so I just picked up three examples but if you know if you see the EG Lib C has a suite of libraries that come with it Lib C is one of them so essentially many times you will see the total size of Lib C is on four meg or something and if you compare with this whole set then the reduction is quite a bit it can get to the half of the size of a fully blown EG Lib C with all the locales and you know message catalogs and everything built in and many times you in embedded systems you really don't want those things so you can easily pull them out so what's missing currently it doesn't do sanity checking for the config file so you have you mistype a option it'll accept it and you miss a dependency it will not take it and you know it will fail to build and if you won't get a sensible message out of the build saying why it failed it will just complain about the missing functionality so this is a problem with the current implementation that I just mentioned earlier that it is pretty homegrown resembles K config but isn't K config so it doesn't do any dependency checks that generally the K config from the kernel will do or it doesn't do other kind of sanity checks that you could get from the K config tools so what has happened in the past year or so Steve Longer beam and one of the developers has posted patches for bringing the kernels K config tools to do the config management essentially into EG ellipsey so the patch has been on the mailing list this hasn't been applied yet but in open embedded essentially we have been carrying it for a long time now we have been forward-porting it and keeping it in shape there are certain improvements that are needed to it which has been commented by maintainers and those needs to be addressed and so that's where the K config patches right now it's not in the sources yet so how we managed to get it to work so there is a tool called K config front-end it's basically if you look at any of the projects which are using K config they have their own copy of K config if you look at busybox it has its own copy of all the tools similarly for EG ellipsey and any other so they occasionally sync with the kernel which is sort of you know pseudo upstream for all the K config work and then they will get all the improvements into their projects and the maintainers have to do that part what we did here is there is a project called K config front-ends it's maintained by the same people who maintain cross tools and the package itself is fairly well maintained it releases with every kernel major release like 3.4, 3.5, 3.6 so you can always have a consistent release of the K config front-ends so essentially that's a dependency we have used so far whether bringing K config directly into EG ellipsey remains to be seen but if K config front-end is available most of the times on all kind of distributions then it's easy to use it because it's a prerequisite now to build EG ellipsey for native across so it supports all the tools that you need mconf and com gconf and so EG ellipsey have been modified so there is an autoconf option which with which you can specify where your K config tools are and if you have standard installation of K config front-ends it will figure it out from user bean and also in all locations but if you have that installed in some different locations then you can specify where the K config is installed and then like kernel you would do like make config to essentially build your final configuration before you start building EG ellipsey so so there is actually some pre-processing and preprocessing that's needed to be done to deal with the traditional options that you know the homegrown system has the options are already defined so it's essentially the tool essentially does is it converts to EG ellipsey naming styles because all the kernel options have to match with config something so the this is a pulse script essentially it runs before on the default config and any defined configuration you have which defines your option groups and then converts that into K config syntax that can be understood by yes ah I see okay yeah we haven't used it but I'll certainly look at it and that's probably a very good thing we can avoid the preprocessing but you know these the patch is almost two years old so yeah correct so yeah so those are kind of improvements like you know we would do moving forward you know when once we get it upstream but that's that's a very good point and essentially reduces the complexity that we have right now to deal with this munging so and then we also have a post processing tool because once K config has done the all the sanity checking processing we have to convert it back into something that EG ellipses build system understands so there is a preprocessing and there is a post processing but if we have that option that as you mentioned then you know these tools can be removed but status code as of now we use those tools and they get invoked implicitly when you are building the config which is the first step and this is again a post processing tool does conversion again into the option group settings that are understood by the EG ellipsey or G ellipsey build system so what it will do is essentially the build system has a another fragment into it which reads the config files and then it has kernel make file style targets that are then optionally added to the build or not so since default is on all of them are added if you have any of them set to know then they will be removed so that's pretty simple so what's the current state in the patches they were discussed on EG ellipsey mailing lists and they were feedback improvements done but after that there are still some some comments that needs to be addressed hasn't been done yet still pending those reviews or in fact those reviews needs to be addressed and as we know that you know a lot of features from EG ellipsey are moving into G ellipsey proper of late and there is a big list of feature list if you go to EG ellipsey mailing this then it lists exactly the amount of the number of features that are in EG ellipsey which are not in G ellipsey are being proposed for G ellipsey upstream which means there will be less and less to carry in G ellipsey in future and certainly I hope that K config is a very good feature that could make into upstream G ellipsey once we have it in in a in an acceptable state and working in upstream EG ellipsey and eventually I think it will be a good improvement into G ellipsey and that's all I have and