Page 1 of 2
How strip down kernel code?
Posted: Sat Jun 29, 2019 9:10 am
by nullpointer
Hi all,
Is there any automated way to extract only the needed code (directories and files), for a given configuration, from the kernel's huge source?
Sorry if this is not the right place to post.
Thanks
Re: How strip down kernel code?
Posted: Sat Jun 29, 2019 7:37 pm
by bzt
nullpointer wrote:Hi all,
Is there any automated way to extract only the needed code (directories and files), for a given configuration, from the kernel's huge source?
Sorry if this is not the right place to post.
Thanks
I'm assuming you meant the Linux kernel. Considering most configuration is done with precompiler #if #endif blocks, you could write a very simple parser script that would cut out the unwanted parts. You can also use gcc for that, check out it's precompiler command line arguments. Deciding which files you will need is a bit trickier.
Cheers,
bzt
Re: How strip down kernel code?
Posted: Sat Jun 29, 2019 9:00 pm
by ~
What code are you looking at?
In any case, just think all the things a program does, then look at each piece as a component to install for your system to work properly.
Then just try to extract the parts you know that do something, until they work with your rewrites.
Re: How strip down kernel code?
Posted: Sat Jun 29, 2019 10:02 pm
by pistachio
~, that is the worst advisement I have heard in a while.
OP: Do not use other people's code and work it into your system. That's a mistake I, and many others, have made. The process is much more enjoyable and informative if you start from scratch!
Enjoy
Re: How strip down kernel code?
Posted: Sun Jun 30, 2019 5:36 am
by nullpointer
Many thanks for your quick replys !
Yes I mean the linux kernel.
Suppose I've configured the kernel for an ARM based board with some drivers only, I want a way to delete all the code which is not necessary for building the kernel (code for other architectures, code for not needed drivers ...etc) .
I hope the question is more clear now.
Re: How strip down kernel code?
Posted: Sun Jun 30, 2019 5:59 am
by iansjack
Is there a particular reason why you want to do this? It won't affect the size of the kernel produced.
Re: How strip down kernel code?
Posted: Sun Jun 30, 2019 8:54 am
by nullpointer
iansjack wrote: It won't affect the size of the kernel produced.
Yes, I know.
Just it helps reducing the size of the archive, I don't want to keep the code I don't need, for the other hand it helps studying the code for a particular architecture.
Re: How strip down kernel code?
Posted: Tue Jul 02, 2019 6:10 am
by Solar
I'll just throw in a cautionary, "you know that you've got to place your work under GNU Public License then"? You might be perfectly aware of that and be "so what?", or it might absolutely not what you would want to.
Re: How strip down kernel code?
Posted: Tue Jul 02, 2019 2:16 pm
by ~
Solar wrote:I'll just throw in a cautionary, "you know that you've got to place your work under GNU Public License then"? You might be perfectly aware of that and be "so what?", or it might absolutely not what you would want to.
If you manage to clean up the code to fully reimplement and learn in the process for everyone's reuse, you can just throw away your code like Programmer's Heaven where programs were made for fun, just to play with the PC.
If you start with any given code not to use it forever as is, but to learn every trick to document it, build generic functions like those from JavaScript, and just throw them away freely to keep everyone's programming fun, you are helping the others as intended.
Even DOS/Windows 9x had that very philosophy of not leaving any single corner unexamined, any single stone unturned, which is what is ideal for the PC platform users, no matter if the environment seems less protected because the intention is to actually understand the ins and outs of the whole machine.
Re: How strip down kernel code?
Posted: Tue Jul 02, 2019 3:47 pm
by bzt
I don't think Solar meant that. I think he meant that GPL is a copyleft license, meaning if you use any GPL licensed source in your program at all, then all your source must be licensed under GPL too. It sounded like the OP wants to strip down the Linux kernel code so that they could reuse it in a simpler form, therefore Solar's note about the license is appropriate and important.
Cheers,
bzt
Re: How strip down kernel code?
Posted: Tue Jul 02, 2019 5:37 pm
by ~
I also wanted a version of the kernel only for x86, but it seems that it needs to be carefully reconstructed from the monolithic source, or trace the code to see where it comes from source, somehow mark with ASCII strings the function names and the end of them for knowing where is each thing for debugging and then just re-copying each element knowing what is included (also, the kernel may have thousand of privileged tricks, but obviously we won't use them all, so we have to know which ones will never run for each of our purposes and strip them as well for a truly understandable system).
I always search any code I have from others to see what I learn, and then I just reupload just like with programmersheaven, codeproject, planetsourcecode, or other old code archives. In my program screens I put that I'm just playing with the PC, as that's what I'm really doing (enjoying what I like the most just for fun), so I cannot care about licenses for my code as it's intended to help everyone interested, and also I know that nobody will really be worried by code I write at the unimportant side of programming, so why not have fun with my own code if nobody will really look at it anyway?
But the main learning is done by meditating on each trick, trying to figure out deeply how to implement each step to make it even possible on my own, with the ideas I get to understand from other's code if any. The end result must be naturally easy to read, it may take several days for a few functions, but the functions that end up being clean from scratch and fully documented/implemented will become part of a permanent API for my projects (any clean functions I write during my life).
The comments have relevant references to files (source, HTML, PDF, execution tracing from manual or execution of specific program regions) I've learned from if appropriate, if they will really contribute to document the code in a functional way for education. The goal is to reimplement the tricks for understanding them and making globally available, not just for the target platform they were written for.
Absolutely everything must be learned from programming and the rest of things that exist, so the original sources and the cleaned-up tricks from our own must be equally understandable for us to be minimally capable of exchanging development with major projects, from initial stuff that a programmer does (calendars, calculators, clocks, bitmap and plaintext editors, command consoles, x86 emulators, from where we can see what the programming standard from another programmer is) to the rest of software available.
Re: How strip down kernel code?
Posted: Wed Jul 03, 2019 2:57 am
by Solar
Looking at licensed code to "learn its tricks" and then writing your code based on that learning experience puts you in a vulnerable legal position. The point
could be made that your work is a "derived work". Lawyers taking apart your code to show where you (consciously or unconsciously) copied from the code you've been looking at and then dragging you to court over it could make your life quite miserable, even if you are being acquitted eventually.
That is why I kept referring to P.J. Plaugher's "The C Standard Library" for the general discussion, but intentionally did
not take his code examples as a starting point for PDCLib, not even for inspiration, because the
code in his book is not licensed for free use. Similarly, I give GNU libc a
wide berth, even when I am stuck and looking for a way out. I do
not want to get entangled in license arguments with the GNU crowd; they're quite organized and vicious about these things.
That's why I cannot recommend consciously copying even a single idea from "looking at Linux kernel code" (except perhaps how to
not do things
), if you're not working under GPL to begin with.
FWIW, I tossed the complete first codebase for PDCLib in the bin when I realized I could not verify that the various contributions I got were "clean", licensing wise. I daresay none of us would have the endurance to go through with a legal action regarding our code bases. We'd probably just fold. That's why I say, "be careful with these licenses". It's much easier to "stay clear" than to clean up retroactively when you no longer even recall where you got a specific idea from.
(While we're on this -- admittedly tangential -- subject, I hope you all have it in writing from your respective employers that they are OK with you working those spare-time projects and won't make any claims on your IP on the basis of you being payed by them for your 9-to-5 work. It
should be self-evident, but some companies / countries have "funny" rules about this, and better be safe than sorry. The laissez-faire attitude can come to a halt abruptly when a legal letter arrives in your mailbox telling you to cease & desist...)
Re: How strip down kernel code?
Posted: Wed Jul 03, 2019 9:32 am
by bzt
Hi,
I completely agree with Solar.
I'd just like to add that GPL is not necessarily bad, it can be a really great license for portable programs with huge end-user base and huge collaboration behind them, like the The Gimp for example, or Firefox etc. (typically what GNU does).
But just like Solar, I also don't think the same license is suitable for an experimental hobby OS without large end-user base, which is often written by one person, or maybe by a small team or group of students.
Solar wrote:I hope you all have it in writing from your respective employers that they are OK with you working those spare-time projects and won't make any claims on your IP on the basis of you being payed by them for your 9-to-5 work. It should be self-evident, but some companies / countries have "funny" rules about this, and better be safe than sorry.
This is interesting. In my country law is pretty clear.
The employer has absolutely no right or claims for the time they haven't paid for. Period. Similairly, the employee can't have claims for things that they create in work hours on the employer's machine. In other words, if you write an app in 9-to-5 on the employer's machine, then all IP goes to the employer, no question asked. If you write an app at home in your spare time on your own machine, then it is your IP, and the employer can't have any claims. (There's one exception, if they can prove that you've used code in your spare-time project that was originally written in 9-to-5 on their machine. But this is not a special case in the law, this stands for any IP infrigiliment).
What's more, no company policy allowed to overrule any law. If they try, the employee can go to a court, and the employee will win. They take this very seriously, because if they don't, that would seem like the government is weaker than the corporations. (Even if that's the case in reality, they would never ever admit that publicly on court, and don't forget that the judge gets his salary from the government...) Therefore companies often blackmail employees that if they go to court then they will make sure of it that the employee won't get any more jobs. But this is a totally different question of illegal company activities and considered a crime.
Cheers,
bzt
Re: How strip down kernel code?
Posted: Wed Jul 03, 2019 9:43 am
by Solar
The issue is more along the lines I outlined in the previous post: A company could make a claim that your spare-time work is "derived" from 9-to-5 work. They can (in most legislations) rule that you may not work on a "competing" product while employed (protecting their IP). If your company is very big and broad in what they do, a transfer to a different department or a new development in your company could suddenly bring your hobby project into conflict with your day work, even when it wasn't when you started.
My previous (2002-2008) employer required employees to "register" hobby projects. Not because they wanted to hinder them in any way, but to remove any legal ambiguity. So they could have a look at what you're doing before there was any disagreement about it. I took the hint and asked my current employer to give me the same kind of "we know, and we agree" about PDCLib; something I am thankful for, because I did learn a lot 9-to-5 which just now starts applying to PDCLib -- namely, Unicode and its intricacies, something I didn't even think about back then. Since the company waived any claims on PDCLib back in 2008, I'm on the safe side.
Re: How strip down kernel code?
Posted: Wed Jul 03, 2019 11:24 am
by ~
I understand that open source in general is OK to use as long as you produce back more open sources for generic use specially if you are the main producer of a project from scratch and use everything else as main rich references, as that's what everyone is doing in those projects, and there are thousands of unnamed authors of small but important patches, unknown other than in the self-documenting mailing lists and other esoteric places, even more for closed source (for example who are the ones who made Windows 98? They seem to be anonymous or are probable the authors from old books and Borland).
Probably everyone here is pointing that this attitude is where the problem starts, a reason that stops people more than what would make them produce more code than what would be used back by everyone. Initially everyone just wants to have fun programming, share their programs and keep things going.
If somebody really doesn't want others to use their code, it's easier that they keep it private forever, share it when they want, but the rest of the code that is public will be easily used as much as any HTML/JavaScript code for any purposes.