I see various instructions on building a kernel. What do each of these steps do? and why are some of them optional - at what time? make mrproper - what does this do? and why not do it all the time make config/menuconfig/xconfig - makes sense make dep - what does this really do. What files does this update make clean - again - if this is necessary, why isn't it part of 'dep'? make modules - almost clear make module_install - so what's this?? why not automatic after 'make modules? FOLLOWING step(s) is very confusing? When do I use the following make Image no it's make zImage - ok, I'll buy that BUT make lilo or zlilo or make boot When do you blow away old modules. Why? Why not just leave them there and compile the new ones. What difference does it make if you have a mess of modules in the directory. Isn't the kernel you built ONLY going to use the code that built in make config - that should be modules? What does depmod do? Sorry if these are obvious to you - but I can't get a straight answer in the books. -- Norman Levin vm/dynAmIX inc. Besked 2 i tr†den Fra:Dan Miner (dminer@edison.chisp.net) Emne:Re: beginner question?? View this article only Nyhedsgruppe:linux.dev.kernel Dato:1999/07/25 Norman Levin (normanlevin@ibm.net) wrote: : I see various instructions on building a kernel. What do each of these steps : do? : and why are some of them optional - at what time? : make mrproper - what does this do? and why not do it all the time This is a severe way to "clean" your kernel tree. It forgets all of the configuration and such. It what people like Linus would do before making a new release. : make dep - what does this really do. What files does this update In C, a program or module can span many files. When this happens, these files are interdependent. So if I change one of the files then when I compile the software, it should re-compile only the pieces which will be affected by any changes in that specific file. The same thing applies to Linux. Because of the steer complexities and size of the kernel, it much more useful to automatically create this dependency information. This is what make dep does. [BTW, mrproper *removes* this information also.] : make clean - again - if this is necessary, why isn't it part of 'dep'? This removes any object files and intermediates (products of compilation) for various reasons (e.g. sometimes dependency info isn't so explicit). In UNIX development, there is a classic structure of handling software builds. configuration [make config, make xconfig, make menuconfig] create dependency info (optional, could be hardcoded) [make dep] build [make Image, make zImage, make bzImage, etc] For if changes are added to code *or* system: clean [make clean] install [make zlilo, etc] distribution [make mrproper] These are building blocks for a developer to manage the software in hopefully a fairly sane and efficient manner. For example, If I change a file and this requires the use of a new module. I need to do some housekeeping now. Why? My dependency info has changed too. However, I don't wish to throw away my object files [it took an hour to get them in the first place!]. --- So, make dep will update the dependency info for me and leave the object files for later use. : make modules - almost clear Modules are dynamically loaded into the system after it's booted. Think of them like generic device drivers. It's much more flexible than this but you'll find SCSI drivers and Ethernet drivers are popular in this form. [Same with filesystems, e.g. MS-DOS filesystem] : make module_install - so what's this?? why not automatic after 'make modules? Because, a developer may wish to test directly and not corrupt his working installation/configuration. Again, the building blocks theme. Compilation and installation are two very different tasks. When you're *ready* to install, then you'll use make modules_install. : FOLLOWING step(s) is very confusing? When do I use the following : make Image : no it's : make zImage - ok, I'll buy that BUT : make lilo or zlilo : or make boot Ok, you're getting confused by historic stuff and convenience options. make Image This was the first target used for creating a kernel -- when it was small. Due to limits in the original floppy bootsector and the progression of boot loaders (anyone remember shoelace back in the pre 0.9x days?), the kernel became too big to be loaded (we didn't have modules then). make zImage This was the first response to the above problem. Compress the kernel and add the run-time support to uncompress it before launching the kernel. make lilo and make zlilo These are convenience targets. They combine compilation and installation (via LILO and a custom script). Personally, I discourage their use. It is possible to compile a bad kernel... *shudder* make boot This is/was a convenience for build a kernel and slamming it onto a floppy in one pass. It's meant only for testing. You'll be wanting to use zImage or bzImage (I like zImage). : When do you blow away old modules. Why? Why not just leave them there : and compile the new ones. What difference does it make if you have a mess of : modules in the directory. Isn't the kernel you built ONLY going to use the : code that built in make config - that should be modules? For me, you blow away old modules every time before installation(*). There are many places for things to go wrong and if you throw time into the mix -- you'll be bald before the end of the year if you develop kernel stuff. :) (*) Actually, I move them into a safe place. Test the new setup.. Once I'm satisfied, I will remove them. : What does depmod do? Back to modules, huh? :) Just like source code, modules can have dependencies to other modules. This program will automatically discover those relationships and remember them. When you do a modprobe, it will consult this information to see if anything should be loaded before the requested module. Examples: vfat, sound support, PPP, SCSI, etc. : Sorry if these are obvious to you - but I can't get a straight answer in the : books. The authors really have a rough time with Linux. Linux moves so fast and has some 8-9 years of history. In addition, many author themselves haven't been around for the complete history. There is only a hundred or so people who can claim such experience (I'm lucky to one of them). All of this history isn't very useful until you want the *big picture*. As yourself, you probably just wanted -- "What? Now, how do I compile this #$@%!@# thing?!" Only now, you're trying to grasp all of its options and you're finding lots of historical fluff which isn't used much any more.