Re: Changing the return value of xxx_attach() from void to int.

[mlelstv%serpens.de@localhost (Michael van Elst)]

uebayasi%gmail.com@localhost (Masao Uebayashi) writes:

>Ideally xxxattach() becomes re-startable and can return EAGAIN so
>autoconf(9) will call it when things are ready.

Why would a driver return EAGAIN and "when" would things be ready?

Is a driver allowed to partially attach() and asked to "poll"
the attach routine until it signals completeness?

As it is now, the driver defers part of the attachment to
config_mountroot() or config_interrupts() and/or signals
with config_pending_incr()/config_pending_decr() that things
are not ready.

To me an exit code of the attach routine can only signal one
condition: the attachment failed and everything is cleaned up,
maybe don't call the detach routine (to avoid keeping state in
the driver), maybe unload a module immediately. That's only
marginally different from the current 'after attach always
call detach to cleanup even partial attachments'.

The exit code shouldn't be used to control the flow of the
autoconfig process "at run-time". We have already too much
of this. The structure of attachments and driver depdendencies
should be kept in the autoconfig tree.


>If autoconf(9) keeps device tree as data, there is little point to
>have call-tree, like  xxxattach -> config_found -> yyyattach ->
>config_find_* -> zzzattach.  Instead autoconf(9) does tree traversal
>while keeping node states.  xxxattach might be called again after
>sub-tree enumeration is done, if necessary.

You could generalize mechanisms like config_interrupts() so that
attachment can be completed in various phases. I don't think that
overloading the attach function is a good idea.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."