On Tue, 21 Jan 2003, Richard Troy wrote: > > Hi All, > [...snip...] > > ...Bottom line: My gut reaction is that it _totally_ _stinks_ if the > answer for a sensible reply to Riku's comments is "you're getting bad > vendor support." Well DUH! You can COUNT ON bad vendor support! So what's > a guy to do? DEDICATE SOME SYSTEMS to doing kernel builds because of a > space issue? What a bunch of crap that is for an answer! > > It is, in my sometimes humble opinion, FAR better to accept shortcomings > than to try and gloss over them with lame excuses. I'd be happier with, > "yeah, but it may get better some day" than "it's all your fault for > having crappy vendors and gee, it's also your fault for not having a > system to dedicate to doing kernel rebuilds!" What gaul it is to tell us > this! -shrug- > Agreed, Thomas appears not to see forest from the trees. He does not understand that it doesn't matter anything that WE can get around diskspace problems with workarounds or having dedicated lab for testing systems before cutover etc, but his brother in law or associate professor next faculty, happy with pretty standard Red Hat otherwise but needs to keep system up2date and get some thirdparty modules easily compiled at the times when a kernel was updated too. I don't know if it's for real that Red Hat considers rebuilding thirdparty modules like from VMWare or like "advanced use" and out of scope, but if they do they haven't realized the fact that nobody really can expect thirdparty vendors jumping jacks every single time new Linux kernel build comes out. There either needs to be a) simple way to rebuild modules or there need to be b) compatibilty over the kernel x.x RELEASE builds like Sun has had it more than past five years. Red Hat already has a), but IT COULD BE EASIER, BUILD MODULES FOR MANY KERNELS ONCE, AND NOT REQUIRE WASTING DISKSPACE UNNECESSARILY. Let's hope the b) will get closer over the time. I've seen/heard Linux module (re)building woes so often that something should be done to improve situation. It doesn't need to be that complicated, all it takes some thought and desire to solve the issue. It doensn't take away somebodys expertise, quite contrary it will let experts or advanced users too accomplish something more valuable with time spent on such trivial issue. And I don't really care if all (including Thomas) understood, it's enough if Red Hat engineers understand and figure out the necessary :) > Oh well, thanks for the chance to rant. Maybe I'll feel better later. > -sigh- > Me too, it's nice to notice at least some see the forest too. Cheers, :-) riku > Richard > > -- > Richard Troy, Chief Scientist > Science Tools Corporation > rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/ > > On Tue, 21 Jan 2003, Thomas Dodd wrote: > > > Date: Tue, 21 Jan 2003 15:39:09 -0600 > > From: Thomas Dodd <ted@cypress.com> > > Reply-To: redhat-devel-list@redhat.com > > To: redhat-devel-list@redhat.com > > Subject: Re: kernel-headers rpm ? > > > > > > > > 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, > > >>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. > > > > > > > > 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 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 ;) > > > > > > > > The 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. > > > > 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. > > > > >>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. > > > > > > > > Not sure. The issue may not have been fully evaluated. > > > > >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. > > > > > > > > Red Hat at least still considers 3rd party drive use "unsupported" and > > building them advanced activity. > > > > >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. > > > > > > > > Note 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. > > 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 delivered > > >four (4) years later. That is some compatibility if you ask from me, > > >and lot to catch for Linux yet. > > > > > > > > That'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. > > > > 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 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. > > > > > > > > 2.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. > > > > >Quite often vendors don't build ready built kernels for each > > >distro prebuilt binary kernels, they don't just bother, sorry. > > > > > > > > That'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. > > > > 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. > > >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. > > > > > > > > So if I install the kernel-source package, what happens to the headers > > installe with the kernel package? > > 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 > > > > > > _______________________________________________ > Redhat-devel-list mailing list > Redhat-devel-list@redhat.com > https://listman.redhat.com/mailman/listinfo/redhat-devel-list > :-) 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
