Re: Boot order

In message <000401c635d3$77f58af0$1318a8c0@paq11>, "Toru Nishimura" writes:
>And the node traversing order is hardly under control even if _deferred
>twist is introduced.  For NV store argument, it's just a sort of how
>to fetch "operating environment," and no more.  Having i2c bus
>node will end up with tree distortion.

Hmm.  I was thinking about this, and one thing that occurs to me is that it
would be nice if, instead of writing config_defer (self, callback), we were
able to specify this where it belongs -- in the config file, which is where
information about device dependencies ought to go.

So, my idea is this syntax or something similar:

	emac0 at pci? defer seeprom0

This indicates that, if emac0 is detected, it should *not* be attached right
away; rather, its information should be stored and tacked onto a list of
deferred devices.  After each device is attached, the list of deferred
devices is scanned in case there are devices there which depend on it, which
then have their attach functions called.

I think this would be a flexible enough solution to cover everything we will
actually ever care about.  Hah!  But it does seem pretty reasonable to me.

Another thing I'd like is some way to register, in the config file, a callback
to be run "immediately after device X is attached".  Thus, if I know that my
particular system needs to do X as soon as seeprom0 is attached, I put

	seeprom0 at iic? addr 0x57 size 4096 callback

and "callback" means that I am obliged to have a function named
seeprom_callback(struct device *) in my code somewhere, which is then
called with the connected device immediately after attach.  (And before
any "defer" items are hit.)

This is just a first pass at trying to describe the functionality we are
currently hacking around a dozen different ways on different platforms.  :)

-s