On Tue, 21 Jan 2003, Thomas Dodd wrote:
> Riku Meskanen wrote:
> >On Mon, 20 Jan 2003, Thomas Dodd wrote:
> >
> >>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
> >$
> >
> >
> That only covers 1 kernel, not the BOOT, smp, uni, uml, bigmem cases.
>
True and very good point. But generally how many of those you
have simultaneously installed, propably two or three right?
However it was I don't think it would stand unresolveable
given second thougth.
> >>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.
>
> 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.
>
Sure it works, but that does not sound to you as a workaround?
It does for me.
I've tried to underline, I'm not looking advise how to use
loop devices or steal space with symlinks from another partition.
I know that stuff. You guys just don't believe how important I find
that what I see with just "df -k", or "bdf" with HP-UX is and that
each filesystem has its own role that should not be twisted around,
even when you can because it will easily bite you later. Every
now and then some clever sysadmin shoots himself or someone else
foot with that kind of stuff.
Think of it like good bookkeeping paractise, you write the cost
to right account and not to account where you have balance and
put a note to right margin where it should really be ... you
see how far Enron and Xerox got with that ;)
> >>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?
> >
> >
> 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.
>
Well, it's questionable matter. You should not name the kernel like
Red Hat and have no problem with that if you use custom kernels, then
just having the pointer to your source accordingly etc. But that is
another issue, I'm more interested that Red Had ready built kernels
would ship kernel includes & config somewhere wit the binary kernel.
> 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).
>
Right, but you should not tamper the Red Hat built kernel tree,
it was not clearly meant for that because the link is not marked
with %config -- and I don't think it's accidentally missing but
rather carefully considered choice.
> >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?
> >
> >
> 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.
>
Right, mostly that is still the case, but I think the tide is about
to turn. I'm not really fond of the idea beginners flooding and having
some compromises persuading newbies, but I clearly understand that some
tasks need further simplifying yet and module (driver) issue is one
of those that needs fixing.
Think of moment that we took here last summer binary drivers for
a old Legato Networker 5.1 for Solaris 2.6 (Sparc) to drive old
DLT-library and they work just fine on Solaris 8 (32bit mode) with
the same Legato Networker that was previously 2.6 and 7 for
some time.
So the binary drivers work fine with the system that was delivered
four (4) years later. That is some compatibility if you ask from me,
and lot to catch for Linux yet.
Not that I expect Red Hat or this list to solve that -- nope,
that is Linus et his pals problems, but still it is something
to think and work towards :)
I know there is some work being done for 2.5, but given
current Linus kernels shape it's not yet time for me to
jump in to play with it. Future will tell if the modules
will work better than this far.
> >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.
> >
> >
> And 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.
>
Quite often vendors don't build ready built kernels for each
distro prebuilt binary kernels, they don't just bother, sorry.
> >just make sure you don't change the location by every kernel
> >release and standardize on something reasonable location.
************************************************************
> They 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.
>
I know it's a big mess now. You, me and many on this list
can figure out how to use it, but don't ask somebody that
hasn't got too many years with Linux yet.
> 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.
I pointed it out too, but 2.4 modules take already around 30M compiled,
also read the two lines underlined with asterisks, whatever
/usr/share/modules/$version the location does not have to be under
root-fs, just shipping the kernel header files with the binary is
what would be important. The only issue with location is that it
rather would not change very often and becomes we well known by all.
I just took a look to 2.5.56/include size and it's been growing
a lot! It is already 29.5M :/ You are right, it's not wise to
put that under rootfs.
> 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?
>
Don't mix up things, Linus kernel is the basis of what Red Hat
starts with. There are many issues Red Hat and many distros
changed before Linus agreed, like installing kernels to /boot
with INSTALL_PATH.
Same thing applies to kernel headers, meant to build modules.
Those dont need to be necessarily under /usr/src/$version/include
if the kernel isn't completely installed. It is completely under
control of distro to provide secondary place where to look if
there isn't source under std location just to enabling module
built for certain kernel.
If you install, non-redhat kernel (std Linus or Alans stuff)
then you are on your own, the system redhat built does not
have to support it. You should have your headers available
as where they always are. No problem with that.
It would ofcourse benefit all if there were some kind of wide
agreement on practise, but all suffering because nobody dares
to step front and solve the issue is plain silly.
Cheers,
:-) riku
--
[ This .signature intentionally left blank ]
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
