On Fri, Jun 24, 2016 at 2:42 PM, Michael van Elst <mlel...@serpens.de> wrote: > 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?
Yes, a vague idea I had in mind is something like that. > 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. This way you can express only "when", instead of "what" (is wanted). > 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. I agree. And I always have a question: if dependencies are kept in the autoconf tree, why do you have to manually call config_defer()? Anyway, I thought I had ideas but apparently I don't. I withdraw from this thread. No objection to the original proposal.