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

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Fri, Jun 24, 2016 at 2:42 PM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> 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?

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.