[lug] ATA driver question

[D. Stimits]

Zulaware wrote:

> This is more of an academic question, since we're moving to a SuSE
> distro w/ ATA driver built-in, but I'm curious.
>
> I was forced to use an older 2.2.x kernel [long sad story deleted] on
> RH7.3 with ATA drives, which worked fine under all tests. The driver was
> from Silicon Images and had to be provided on disk during install (and
> recovery) using the "dd" option. The problem came when I upgraded the
> kernel to whatever RedHat Network provided. Upon reboot, it had a kernel
> panic trying to mount any partitions.
>
> Is the driver somehow attached to the kernel when using dd? or is it a
> kernel incompatibility with the drivers? If I were to go back to this
> configuration (which I'm not) would I have to reinstall the 3rd party
> driver for the new kernel, and how is that done?

Don't know about your particular driver, but you have basically two 
choices when a driver is installed. First, it can be built into the 
kernel...obviously not the case for your driver. Second, it can be built 
as a module and loaded by the kernel...this is the case for you.

But if the driver is required to access the disk with the driver, you 
have a problem. So the module has to be preloaded or loaded by some 
means other than access to the hard drive which the driver provides 
access to...kind of obvious logic if you look at that statement, worded 
this way, it seems silly to have to state that. So the driver is stored 
by any means that is built into the kernel, and retrieved/loaded prior 
to actualy hard drive access. An initial ramdisk (see man mkinitrd) is 
used for this purpose if the driver is available during setup of the 
boot loader. Since your driver is unknown to the distro creator, a 
floppy is used. If your kernel had built in access to something like NFS 
mount code, you could do the same with PXE boot (common for diskless 
systems). If your system had some snappy little web retrieval mechanism, 
then the driver could be downloaded from a web URL (kickstart can do 
something like this). You get the idea.

The driver module itself is binary data. It is compiled against a 
specific kernel, and the kernel maps offsets in the module to various 
function interfaces. If you alter the kernel configuration, one or more 
binary offsets will change in the kernel (the kernel will look for a 
given function interface at a given offset that is the same offset if 
the configuration is the same...once configuration changes, all bets of 
constant offset are gone). So even if you have the driver image, it is 
possible that the kernel involved would hunt for function offsets at the 
wrong address (offset) when changing kernel configs, and fail. dd is 
used to copy a driver bit-for-bit exact, without regard to filesystem 
type; if the image copied has its offsets at the wrong location, it 
won't matter (in general, there are relocateable code schemes if you are 
willing to enlarge an image with symbols, and add the support to search 
for symbols instead of the faster assumption of fixed offset map...both 
loader and module have to support this or it is useless; hybrids can 
also be built).

Then again, sometimes with major version changes in kernels, certain 
internal functions (system calls) can change or be removed...if the 
driver uses something changed or removed it fails, and this would be an 
incompatibility with the kernel. If it fails due to looking for 
functions at the wrong offsets, it can be cured by recompiling the 
module against the current kernel configuration (the compilation against 
the exact config would place functions at the right offset). Every time 
you recompile a kernel with a new configuration, you will find you need 
to rebuild a new initrd for any module required prior to disk access; 
you will also have to recompile modules to follow the new kernel offsets.

D. Stimits, stimits AT comcast DOT net