Riku Meskanen wrote:
On Tue, 21 Jan 2003, Thomas Dodd wrote:
I don't think so... If adding a new disk is not possible, use a file,Sure it works, but that does not sound to you as a workaround?
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.
It does for me.
Yes, it's a workaround but ...
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.
df will list the loop mounted filsystem and how much space it has.
Think of it like good bookkeeping paractise, you write the costThe whole issue is more a temporary work around. You either realocate the space to proper partitions/filesystems, or you nolonger need the space anyway. So the "admin" box has a lot of space in /usr/src for building all thes 3rd party drivers. That machin is used to build the kernel/drivers for all the others (possibly one for each major arch, like x86, ppc, sparc, parisc. crosscompiling is such a pain to get going) and then distribute the kernel and driver to all the other machines together. Most machines don't need the extra space.
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 ;)
Same goes for upgrade to new releases. You test/setup every thing on a development machine. Once you have it read, you use kickstart to upgrade the machines and add the custom driver in the %post section.
Right, but you should not tamper the Red Hat built kernel tree,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 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.
Not sure. The issue may not have been fully evaluated.
Right, mostly that is still the case, but I think the tide is aboutRed Hat at least still considers 3rd party drive use "unsupported" and building them advanced activity.
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 forNote the Solaris 2.6 to 8, while it spaned 4 years, is only 3 releases. That about the same as RHL 7.1, 7.2, and 7.3.
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.
Or was that a 2.6.1 release? I know 7 and 8 never had point releases, really being 2.7 and 2.8, all part of the Solaris 2 series, aka SunOS 5.x.
So the binary drivers work fine with the system that was deliveredThat's another issue. If you remove/ignore module versions (the embeded one) you can get similar longevity/compatibility. If you build a 2.2.x kernel with gcc-2.7.2, and a 3rd party module with the same compiler, then later, build a 2.2.y kernel with the same compiler, you can use the old module for most cases of x and y. The same is true for 2.4.x and 2.4.y, though I think there have been more incompatible changes in the 2.4 series.
four (4) years later. That is some compatibility if you ask from me,
and lot to catch for Linux yet.
The open source worl has much faster cycles though. So the span form 2.2 to 2.4 kernels is smaller. The gcc compiler has been undergoing a lot of changes as well, so 2.7.x, egcs, 2.9x, 3.0, and 3.2 have som incompatible changes. Not sure of all the differences. MODVERSIONS was developed to help preven one from loading incompatible modules in the kernel, but it can be overridden. Look at the work arounds for the NVIDIA 3d drivers when RHL-8.0 was released, and the compiler changed from 2.96 to 3.2. I never tried, since I don't use the NVIDIA drivers, but you probably could have rebuilt the kernel using the compat-gcc (2.96) and the driver would have worked.
The 7.x series is probably compatible, using the 2.96 compilers, once you update 7.0 to a 2.4 kernel. Again, I'm not sure about the changes in the 2.4 kernels that would be incompatible, a kernel developer would know more.
I know there is some work being done for 2.5, but given2.5 wil be released as 2.6, and will be incompatible with 2.4 modules. If you stick with a compatible 2.6 kernel, same gcc (no major changes), and glibc, then modules will probably be compatible for a while. In the past it has taken a while for the kernel to stabalize after release, but by 2.6.5 I expect comptibility to stay through most of the 2.6 series.
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.
Quite often vendors don't build ready built kernels for eachThat's a vendor support issue. When Red Hat releases a new kernel, there's a reason. You vendor should release a new driver for the new kernel. If they release binaries for a small portion of the kernel, then that's only partial support. Ask them what to do, either run a kernel that should be updated for security or stability and change hardware, or use a buggy kernel with their drivers.
distro prebuilt binary kernels, they don't just bother, sorry.
If they are supporting Red Hat Linux, they should have system with all supported versions, kept up to date. When a new kernel is released, it should only take a day to have updated binaries available. Since this is ongoing support, it should be automated per OS release, for all architecture supported. Basically( for RHL-7.1+):
rpm -Ivh kernel-source
foreach i (`ls /usr/src/linux-2.4/configs`)
cd /usr/src/linux-2.4
make clean
cp configs/$i .config
make oldconfig dep
<build and package driver>
end
So That mostly lazyness and poor support from the vendor. What if M$ released a new DirectX than needed new drivers, and the vendor didn't release one? Of course the vendors work with M$ diuring the development of DirecX to make sure they have drivers ready when it's released. Are your vendors working with Red Hat, Mandrake, or SuSe during development? Or XFree? Or Linux and the rest of the kernel developers?
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.
That include architectures other than x86, which redhat doesn't ship.
Same thing applies to kernel headers, meant to build modules.So if I install the kernel-source package, what happens to the headers installe with the kernel package?
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.
Which ones would the 3rd party drivers use by default?
-Thomas
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
