On Sun, Feb 23, 2003 at 12:50:59AM +0200, guy keren wrote: > > On Wed, 19 Feb 2003, Muli Ben-Yehuda wrote: > > > On Wed, Feb 19, 2003 at 11:58:16AM +0200, Eli Billauer wrote: > > > > > original configuration, and noone was really sure. I don't think that > > > there is someone here who can tell me exactly what files are tampered > > > with during all the makes (could syscalltrack be handy here? ;). All > > > this makes kernel compilation a mysterious adventure, with no promised > > > way back home. If there was as little as a list of directories to back > > > up before starting, it would all look different. > > > > Eli, > > > > It's not voodoo. It's not a mystery. It's code, plain and simple, > > there for the reading. Please read the Makefile and write a > > comprehensive list of files which are changed. I'm sure > > kernelnewbies.org will be happy to put it on line. > > actually, there's a contradiction there. if it was that simple, there > would be no need to write a doc for it and place on kernelnewbies.
I didn't say it's "simple", I said it's "code, plain and simple". as in "you have the documentation, it's the code". > Makefiles are usually hard-code to read, and writing Makefiles which are > easy to maintain as well as easy to read, is a difficult task. > specifically, the Makefiles of the linux kernel are not easy to figure. > the fact that you deal with them for quite some time now, and you read > them rather easily, is not an evidence to how easy it is to read them for > the first time. this is especially tru when you have a specific goal in > mind (such as - how do i get this module to work). I agree here. > > > Don't take me wrong: I think that the possibility to compile the kernel > > > is one of the beauties of Linux, and writing in kernel space is > > > something I know I'll do sooner or later. The problem is that it's such > > > an unfriendly field, and for no real reason. > > > > Did you read the books? did you read the source? where else did you > > expect the knowledge to come from? > > from good documentation, ofcourse. the linux kernel comes with lots of > documentation, but without something large to show the architecture of the > beast, and how it all fits together. specifically, i'm not aware of good > documents that deal with the Makefiles - is there? for the kernel itself > there is 'the linux kernel' in the Linux Documentation Project - thoughts > its not deep enough for my taste. Linux Device Drivers, 2nd Edition (available online). Understanding the Linux Kernel, 2nd Edition (highly recommended). The linux-kernel mailing list archives. The lwn.net kernel summaries (very highly recommended), and kernel traffic. http://www.kerneltrap.com, http://www.kernelnewbies.org. As for the Makefiles specifically, in 2.5, 'make help' should be a pleasant surprise, the Makefile begins with a documentation section and there is Documentation/kbuild/*. 2.4 is not quite as well endowed, but neither is it completely lacking. > > > >c. Run 'make oldconfig; make dep'. This step prepares the intermediary > > > >kernel configuration and build files that are needed for the build > > > >process. Amongst other things, it handles module version. > > > > > > Thanks. "make oldconfig" was the secret. And a secret it is. Just for > > > the fun of it, does anyone know exactly what it does? What "old > > > configuration" are we talking about? And "make dep" afterward fixed > > > it all. > > > > It takes .config, all of the configuration symbols in this kernel, and > > only asks you about new or changed configuration options. It's used > > when you already built a kernel, and then a new version is > > released. You copy the same .config over and run 'make oldconfig', and > > instead of dealing with hundreds of configuration options, you only > > deal with the delta. > > > > As a side effect, it also creates some files that tell the build > > system that it has been configured, and (I think) creates the > > include/asm-$(ARCH) -> include/asm symlink. > > just as a note - i have been compiling linux kernels for several years, > before i heard about 'make oldconfig' for the first time - and i did read > some of the documentation that comes with the kernel during that time. in > fact, i got so used to reconfiguring it manually, that i keep forgetting > about 'make oldconfig', and thus configuring a new kernel keeps taking me > 30-60 minutes every time ;) You should start doing it 15 or 20 times at a stretch, that will cure your memory in a hurry ;-) Here's my currently running kernel: [EMAIL PROTECTED]:~$ uname -a Linux tea 2.5.62-mx #34 SMP Sat Feb 22 09:28:42 IST 2003 i686 unknown the #34 there means that it's the 34th compilation of this kernel tree... > > > >Start with the top level > > > >Makefile and Rules.make, and follow what happens when you run 'make > > > >oldconfig; make dep'. > > > > > > > Yeah, right. I wanted to install a linmodem driver, not explore the > > > mysteries of makefile, sed and bash, and virtually every possible system > > > file. > > > > You want knowledge. I told you where it is found. > > sometimes, this is like sending people to look for a needle in a haystack > (thanks for 'man strstr' for showing me the proper spelling). what you say > is 'installing a linmodem driver requires good understanding of the kernel > build system'. as a comparison, apache has 'extension modules', which can > be compared to device driver modules. the apache team made osme work to > make it easier to compile such modules - and wrote documentation > specifying how to get this done. nobody did that for the kernel, so > far. As I mentioned, out of tree modules are step children, and very little effort goes towards making sure their build works. The onus is on the people who choose to maintain their module out of the tree to provide a comfortable user experience. > > > I have only one explanation for all this: Kernel hackers enjoy the > > > exclusiveness of their status. It's Open Source, but closed society. You > > > want to join it, fine, but you'll have to go through some acceptance > > > tests before you can do anything. > > > > No. You'll have to invest effort and show that you know what you are > > doing. Otherwise, just pay someone to do it for you. > > muli, i think you're confusing the developers and the users. for a > developer, it is ok to expect them to learn how the thing works > internally. for users - it does not have to be a mandatory thing. the fact > that it is, is not a positive sign for the linux kernel's usability. > this possibly stems from the open-sourceness stand of the kernel people - > they want drivers to be open-source and placed inside the kernel. the > problem is that this system goes against any newly developed driver, that > was not added to the kernel yet, for one reason or another. Don't confuse "out of tree" and "not accepted into the kernel yet". The kernel developers want kernel modules to be distributed as patches to the kernel (in which case, they haven't been accepted into the kernel yet, but they are NOT being built "out of tree") and not as stand alone packages, which are configured and build outside of the kernel tree. Again, if a developer decides to build his module outside of the tree, for whatever reason, it is his responsiblity to make sure it works. Why should the kernel developers invest support in a deprecated (not officially, but in practice) feature? FWIW, syscalltrack is also guilty of having to be built out of the tree and not being easy enough to build this way. Care to send a patch? :P~~~ -- Muli Ben-Yehuda http://www.mulix.org -------------------------------------------------------------------------- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
