On Mon, 20 Jan 2003, Thomas Dodd wrote: > > Riku Meskanen wrote: > > > >Some thoughts about the current kernel module compilation issue ... > > [ I don't know how much worth there is posting these opinions or proposals here ... I don't know if anybody from Red Hat still reads these or if he does just few first lines or so -- or that is at least how I feel given the response rate from Red Hat engineers recently (past year actually). Anyway, here we go again ... If you are real busy, just skip to ** point being ***, please.] [ But if they do listen, there is nice relatively new software at http://www.stud.uni-hamburg.de/users/lennart/projects/ifplugd/ which offers the ethernet interface activation and deactivation when the cord is plugged and unplugged -- a very nice utility for laptop users. Ok, that was just a teaser to continue reading. ] > >I've been wondering why require the full kernel source package > >(/usr/src/linux-$version) which size is about 137MB installed > >at /usr, while the (/usr/src/linux-$version/include) headers > >needed to build modules fits fine on 8.5MB. > > > > > You also need different headers for each arch, or smp. You need to: > cd /usr/src/linux-<version>; cp configs/kernel-<version>-<arch>.config > .config; make oldconfig; make dep > Yes, I know. All those 'different' headers count together less than 8.5M and (make dep) .config does not add much. $ du -s /usr/src/linux-2.4.18-17.7.x/include 8408 /usr/src/linux-2.4.18-17.7.x/include $ > to get the headers ready for building 3rd party modules. > > >Often the space in /usr is so short that freeing some space > >(provided LVM was not used) is a PITA. Not that I defend bad > >fs-planning done earlier, but we all propably have met and > >tried upgrade the system which /usr didn't appear as much > >free space there once we thought would be enough. > > > > > so make /usr/src a seperate filesystem/partition. > Right, provided you have free space or can install new disk or if you really like to get deeply involved just install the whole system again to free space at /usr ... and I bet you did not get the point, me thinks. > >So how about having this very small 8.5MB portion installed > >also with binary kernel to /lib/modules/$version/include ? > > > > > Because the correct place is /lib/modules/<version>/build/include The > whole pourpose of the build symlink was to make finding the build tree > easier. Nothing says that it must point to /usr/src, it can point to > $HOME if you wish. > Ofcourse it can, but it's not when it comes out of box and many don't install kernel source by default so there is nothing (the link is broken). You describe a workaround, not a solution. I was talking about the latter, not the former. Besides, the /lib/modules/$version/build is just a symlink, but if you change that you actually break integrity of the kernel rpm because it's not defined as %config file. It was thus not meant to be changed and you get compliaints if you do from rpm -V, right? Ofcourse, anything on Linux can be changed, that's what the source is for. It's however wise to minimize any changes unless you like to maintain your local customized distribution and then it's not any more Red Hat's issue and OT on this list. Any files rpm distribution has not defined %config, should not be touched. You can list %config files with rpm -qc some-rpm-package, if you did not notice it yet. It's ok, to add things (like modules), edit configs etc, but caveat emptor especially on upgrade, if you change things the distro was not prepared. And if you need to change things, prepare your custom packages and document what you modified, so that you can revert changes before upgrade if it's *really* important that upgrade does not break anything. Then if you still need customized packages, because some feature is still not in distro, prepare upgraded packages for the newly upgraded system. Keeping the system clean and consistent is the single most important issue for successfully being able to run systems many years with little downtime and being able to easily upgrade. I'm not willing to trade of that benefit for quick hacks. Seen so many times when the it's got out of hands and only reasonable mean to get system back in line is to do complete reinstall and document properly for future needs what had to be changed. There is big difference how systems should be administered and how many 'administer' systems. I don't see any reason I would like to be part of the latter when I know how to take care things they should. (It is part of my profession to know things should be done, not 'just get the job done' and escape from the scene promptly.) IMHO, I find it ok to use ant dirty tricks to get broken system up and running once, but it should be fixed ASAP properly or dirty tricks gets forgotten and becomes commodity. Removing hacks afterwards is important if the system has any value to anybody. This is the reason for me to look for the solution, not just a workaround. The principles outlined apply to any systems, not just Linux. > >but it can get much too complicated just to have modules built > >and installed for all installed binary kernels at once. > > > Building 3rd party modules is not something most users would do. Either > they stick with the Red Hat kernel and what it supports, or they get > prebuilt modules for their current kernel. Few have more that on kernel > installed for more than a few hours, lonenough to reboot the new on and > remove the old one. > I beg do disagree. First with your presumption what counts as a user. You seem to define all the users by lame windoze losers with no clue nothing but wagging the mouse. Can't we have a bit more wide view here, please? I agree that ordinary beancounter working nothing but with corporate payroll and productivity tools should not try building modules. He/She does not really know what he is using and that does not matter of fact count long as it works. Besides, He/She is usually behind the FW etc. But it is not appropriate to treat all Linux users by some narrow scenario. There are plenty of users who manage themselves all common aspects of some distribution fairy well, they have no incentive to build new kernels thou. [ ** point being ** ] They are happy with the kernel that comes with the distribution and then from upgrades when it's time to upgrade for security reasons etc. (It's not really option skip upgrades unless you are off the grid all the time). Second, just keeping your system upgraded, with the Red Hat provided kernel upgrades and find for example that your copy of VMWare <URL http://www.vmware.com/> does not work if you don't "vmware-config.pl", which does not ship ready built modules nothing but the few initial kernels found from some distros. Thus to make vmware working again you need to install kernel src package, make dep and then vmware-config.pl. Voilá, not that hard, but it could be easier. The same procedure applies to many other thirdparty software with modules, ethernet, wlan, touchpad etc. adapters you propably have if you have a recent laptop and would like to take some advantage of features built in. So, why require the kernel source 137MB overhead to /usr/src when the whole issue could be solved nicely with installing 8.5M kernel headers for example /lib/modules/$version/include with the binary rpm-packaged kernel you need have anyway. The bonus: the thirdparty modules could very easily check, build and install if given permission for all installed kernels at once. No strings attached. The only bad point I see here that it's not yet custommary to have headers at /lib/modules/$version/include but if that matters the location can ofcourse be something else too, just make sure you don't change the location by every kernel release and standardize on something reasonable location. The real point being is, distribute the required kernel headers & .config with the binary kernel and most module building issues people have are gone. Cheers, :-) riku ps. If someone would like to submit this as a RFE on bugzilla, then please do. I've lost my account password to redhat site and can't get hold on my past email account I had when registering. I rather not also get another (new) handle as I'm used to have the same on all sites. (I tried to ask help last fall from redhat support with not that much help, all I got was some std message with no convergence with the issue :/) pps. I'm sorry it became so long ... -- [ This .signature intentionally left blank ] _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
