Re: AIC94xx SAS question.

["Raoul Bhatia [IPAX]" <r.bhatia@ipax.at>]

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@ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office@ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________