Wakko Warner wrote: >>> lib/firmware/aic94xx-seq.fw ... >>> I'm not sure if the driver compiled for SuSE "just knows" to look in >>> /lib/firmware, or how it finds the file. It might have something to do >>> with the firmware_class module in SuSE. >>> I do remember that I needed to load 'edd' before 94xx, or it would not >>> init the firmware. >> this is a default behaviour of this and many other drivers. > > Which part are you refering to as being default? Requiring edd or something > else? the driver finding the firmware by itself. in my hurry, i missed the "edd" part ;) >>> As for compiling the driver in the kernel, and putting the firmware in >>> initrd/initramfs, you would have to force the init of the 94xx module to >>> be after the initrd/initramfs was initialized, loaded and mounted. I >>> have not checked to see if that is currently possible. >> in the end, there is no big deal in putting the firmware into the >> initramfs. some distributions may work out of the box, some might >> require a little tuning of an initramfs hook. > > I compile kernels specifically for each machine that I have (which is not > that often and not that many). Some mount NFS root, others have different > drivers required to mount / and other CPU options as well. Thus I do not > need the extra overhead and complexity of an initramfs. i used to do this too. and on special systems, i still am in favor of compiling my very specific kernel - maybe even without module loading support. but for 99% of the servers i am taking care of, i abandoned this in favour of simply having to use apt to upgrade these systems. given my available time vs the time the compilation for the different systems would need (ok, i know that you can set up some build environment which compiles a kernel for every type of configuration you want) i happily accept the loss in performance, etc. that comes with it ;) >> which leads me to my question: why are you absolutly against an >> initramfs image? properly configured - and that is not a big deal >> in current versions of mkinitramfs and current distributions - there >> are few possibilities to break the setup. > > I've always hated the idea that one would require this just to get their / > mounted. Granted there are some setups out there that absolutely require > it. I have one such setup at work, but that system was designed to run out > of ram anyway. > > See comment about initramfs above. Now if I were attempting to mount > NFSroot over wireless, I would have to use an initramfs. I see no point in > using initramfs for something that can simply be compiled into the kernel. > I am aware of possible hardware changes (IE going from ata, scsi, etc to > sata or sas) that would require a recompile and I prefer this again over > initramfs. i used to think the same. plus i thought about the extra performance of disabling module support/interfaces plus the additional security which you gain when there is no module-support compiled into the kernel. see above for my conclusion. > As for the reason for this thread, the AIC94xx chip requires non-free > firmware. Right now, my / is on SCSI and is compiled in. I had considered > re-doing my system and doing away with the SCSI hard drives. That'd mean > that I'd need the driver in the kernel (Key word is "I"). So how do I go > about getting the firmware to the driver. My 2 options, if doable, is to > somehow build the firmware into the kernel myself or build an initramfs with > just enough tools to load the firmware into the driver and mount my /. i know the problem with aic94xx - we initially struggled too because the aic94xx was the first driver we needed the firmware for to mount /. i'm still in favour of initramfs as this, imho, made testing easier too ;) > I still like the "There's more than 1 way to do it" and I'll probably do a > different way for anything =) good - feel free to post your patches/changes/etc. ;) cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@xxxxxxx Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office@xxxxxxx 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
