uebay...@gmail.com (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: mlel...@serpens.de "A potential Snark may lurk in every tree."