Re: [Wg-test-framework] linux 3.14.34 failure to detect disks on C600 storage controller

["Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>]

In re: Initialization order.  The initialization order is not `supposed` to 
change.  The idea is that the automatic loading of modules is keyed by external 
symbols.  When the kernel references a symbol in a module it loads the module 
containing that symbol.  If that code is built in it just does the reference, 
no need to do the module load.

Having said that notice the quotes.  Even if the order doesn't change there 
will definitely be latency effects as it takes longer to get a module into 
memory.  Theoretically modules are totally transparent.  In practice they can 
bite you.

PS:  Two things about Linux that I've always hated - modules and initfs 
(actually one thing, modules, since without modules we wouldn't need an 
initfs).  I've always felt that it's open source, you have access to the source 
by definition.  If you want to add something to the kernel recompile it, 
there's no need to deal with binary blobs.  Yes, I realize that modules are a 
god send for the distros but I still hate them.

PPS:  I guess I'm showing my age since I worked on Linux before it had module 
support.  Pretty soon I'll be yelling at you whippersnappers to get off my lawn 
:-)

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx] 
Sent: Friday, April 17, 2015 2:50 AM
To: Ian Jackson
Cc: Dugger, Donald D; wg-test-framework@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [Wg-test-framework] linux 3.14.34 failure to detect disks on C600 
storage controller

On Thu, 2015-04-16 at 19:11 +0100, Ian Jackson wrote:
> Dugger, Donald D writes ("RE: linux 3.14.34 failure to detect disks on C600 
> storage controller"):
> > I still think it's the initfs.  There's a lot of magic that happens when 
> > creating the initfs and I've been burned by the magic getting confused in 
> > the past.
> > 
> > I guess I need to understand your build process better.  If you are 
> > building a kernel on machine A and then booting on machine B you can get 
> > hit by subtle issues in the build process.  The biggest issue is that, when 
> > creating the initfs, by default the system identifies which kernel modules 
> > to include in the initfs based upon what kernel modules are currently 
> > loaded on the build machine.  If your build machine, for example, is using 
> > IDE disks and the target machine is running SCSI expect to have problems.
> 
> The initramfs is built on the target machine.  So I don't think this 
> can be relevant.

FWIW I agree, AFAIK osstest does the completely sensible things here which 
should be expected to work.

> > On a related note, I've run into issues where Linux has split a 
> > module into 2 separate modules which confuses the initfs magic and >
> required manual intervention.
> 
> That would be a potential cause.

One thing I wondered about was an interaction between bits which are =y and 
bits which are =m, i.e. some bug where FOO=m relies on BAR=m and if BAR=y it 
gets confused (i.e. because the initialisation ordered is perturbed by making 
BAR=y).

Ian.

_______________________________________________
Wg-test-framework mailing list
Wg-test-framework@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-test-framework