Riku Meskanen wrote:
On Mon, 20 Jan 2003, Thomas Dodd wrote:
Yes, I know. All those 'different' headers count togetherYou 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
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
$
That only covers 1 kernel, not the BOOT, smp, uni, uml, bigmem cases.
I don't think so... If adding a new disk is not possible, use a file, the wonder of loop devices :) While people regularly use loop mounts for CD and floppy images or the initrd, they forget that almost any filesystem/mountpoint can be a loop device. I did this recently for /var/spool/up2date. The system is mainly a wi98 box, but it has a small linux install. So when I didn't have room for new updates, I tried a symlink. For various reasons it didn't work well, symlinking /var/spool/u2date to a FAT32 filesystem, so I created a new filesystem using the loop device and a file on the FAT32 filesystem. dd, losetup, and mke2fs where all it took.Right, provided you have free space or can install newso make /usr/src a seperate filesystem/partition.
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.
Then that's a bug in the rpm, that should be fixed. But, the Red Hat kernel-sources installs there, so the Red Hat kernel rpm points there. If you use a build tree somewhere else, the link will be to that tree.Ofcourse it can, but it's not when it comes out of boxBecause 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.
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?
The WHOLE point of the build link was to make it easy for 3rd parties to find the kernel source tree, mainly for building drivers (modules) that aren't distributed with the kernel yet (if ever).
It's ok, to add things (like modules), edit configs etc, but caveatAll changes should be documented. And symlinks that the installer might see need to be relative. I got bit by that one. link /usr/src to
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.
../home/<user>/src not /home/<user>/src.
<snip>
I agree with all that on admin and hacks.
That is who Red Hat is designing the system for. More "advanced" users learn all the other things you can do. And linux is really ment for those who have learned, while M$ Winders stays at the "beginner" level for ever.Building 3rd party modules is not something most users would do. EitherI beg do disagree.
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.
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?
Second, just keeping your system upgraded, with the Red HatOr a new module from VMWare for the new kernel. They used to document this. Same for NVIDIA.
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 softwareAnd you either wait for them to release a driver for the new kernel, or build one you self, following their instructions. If you downloaded a prebuilt driver, they will probably soon have a driver built for the new kernel. If you built your own, you pobably updated the kernel-source too.
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/srcThey are already supposed to look in /lib/modules/<version>/build/include, and are starting to do so. Since the <version> string for the different RedHat kernels includes the smp, bigmem, or BOOT strings, either the kernel should include the headers, installed in /usr/src/linux-<version>/include, or a seperate package to put them there. The config file IS currently included, in /boot/config-<version>. The kernel-source package then installs in the same place as the uniprocessor headers. Then you have the issue of files belonging to 2 packages.
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.
Adding a copy of the headers in /lib/modules/<version>/include has other issues. One it uses space on the rootfs which may not be very big.
Whose job is it to install the headers? I think it need to be the kernel (from Linus and Co.), so if one installs a non Red Hat kernel, the headers are still there.
What stage of the build does that?
If I build a monolithic kernel, should I still get the links/file in /lib/modules ?
How are 3rd party devlopers to search all the possible locations?
What if Debian, Mandrake, SuSe and other don't do the same?
-Thomas
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
