Jason Thorpe wrote:
>
> 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.
>
> -- thorpej
So, what would be cleaner, IMO, is to have a way for a driver to call
into another driver cleanly in the kernel.   And to express the ordering
dependency.  Here's something like what I suggest:

drv_attach("drivername");
(one could imagine another variant that registered a callback:
drv_deferred_attach("drivername", callback);

Also, then you you can do things like:

vn = drv_open("/dev/path", perms, credentials, flags);

or maybe

vn = drv_open("driver", instance, flags);  (assumes root credentials,
may or may not be a good idea.  think the previous /dev/path is better
so you can check device permissions e.g. to inherit restrictions.

then you have operations:

x = drv_read(vn, count, buf);  and so forth.  most especially I want
x = drv_ioctl();

Which will cover most of the GPIO and such cases.

And making this runtime like this removes the "static" dependencies, but
it *does* create a need for the driver to know what its own direct
dependencies are.  Not an unreasonable requirement, I think.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191