In message <09B32E91-D5F7-45E2-814C-047345DBC3B1@shagadelic.org>, Jason Thorpe 
writes:
>
>On Feb 20, 2006, at 6:46 AM, Martin Husemann wrote:
>
>> I ask because I personally do not like ordering requirements inside  
>> config
>> files. I see your problem, and the question is: what other options are
>> available to solve it.
>
>Ordering of probes like is being suggested is completely bogus.  It  
>further entrenches us in our outdated, static mindset.

Well, the alternative proposed appears to be to essentially completely
duplicate the entire i2c bus architecture in a given platform's machdep.c,
giving us two copies of all of that code, and leaving it subject to bit rot
and divergence.

My thinking is that, since we have working code to read this device, we should
use that code rather than making a special duplicate copy just for this one
circumstance.

I guess I don't understand the term "static mindset" here.  I'm targeting
a piece of hardware which is not expected to change, after all.

This seems like a platform issue.  For a laptop or even desktop kernel, it's
nice to be able to plop the drive in a new machine and have it Just Work,
without a Windows-style reinvention of the kernel which involves three reboots
and a megabyte or five of downloads.  But I'm not targeting one of those; 
I'm targeting a customized piece of hardware where kernel memory is expensive,
and I don't want to fill drivers (like the emac driver, which only runs on
weird hardware like this) with special case code to handle a specific machine.

-s