Re: RFC: device attachment/detachment

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Quentin Garnier wrote:
> On Sat, May 02, 2009 at 09:55:01AM +0200, Christoph Egger wrote:
>> Quentin Garnier wrote:
>>> On Sat, May 02, 2009 at 12:56:43AM +0200, Christoph Egger wrote:
>>>> Drivers attaches in the device tree independent if their attachment
>>>> function failed or not. The autoconf framework isn't aware of this,
>>>> because the attachment function doesn't return an error code.
>>>>
>>>> dyoung@ started to work on the drivers to detach the drivers
>>>> on shutdown/reboot. The drivers' detach function doesn't know if
>>>> the attachment failed or not. It only can carefully
>>>> check which resource was allocated and which not and free the
>>>> allocated ones.
>>> No matter what happens, one has to be careful not to free resources it
>>> didn't alloc.  I don't see how anything could change that.
>>>
>>>> Attached patch modifies the driver's attachment function to
>>>> return an error code, zero for success.
>>> While I understand where this comes from, autoconf(9) has more short-
>>> comings than just that one, and fixing them will require touching every
>>> single driver in the tree, too.  I'd rather see that done just once.
>> Can you enlist all shortcomings, please ?
> 
> In a nutshell, autoconf(9) doesn't allow a device to exist without a
> driver attached to it.  That's why there is an on-going effort to split
> the struct device from a driver's softc.  It is a necessary step to more
> radical changes to the autoconf(9) API.

In fact, the work on device_t/softc split is stalling. So it's an
open-end task.
What are the autoconf(9) API changes you're talking about ?

> [...]
>>> You can't move the attach callbacks around the call to
>>> device_register().  (I'll grant you that it is #if 0'd in the pseudo-
>>> device case, but it might not stay that way eventually.)

ok, I moved it back in my tree.

>>> device_register() has to happen before the attach callback because the
>>> system will typically set properties for the attach callback to use
>>> during that call.  I don't know how device_register() users could
>>> react if the device they've just messed with disappear immediately.  It
>>> has to be checked carefully.
>> On x86, device_register() is used to set bootdev. When prompted for
>> the boot device, the failed devices shouldn't be listed.
> 
> Is this why you did such a change?

Yes. And from code reading it sounds more logical to register a device
_after_ it successfully attached.

>> When other platforms do other things that need to be undone, then
>> we need a device_deregister() for autoconf's error path.
> 
> And the detach path too.
> 

Right.


Christoph