bus device/ivars
Warner Losh
imp at bsdimp.com
Thu May 31 16:28:13 UTC 2012
On May 31, 2012, at 9:54 AM, John Baldwin wrote:
> On Thursday, May 31, 2012 4:19:46 am Norbert Koch wrote:
>> Hello,
>>
>> I have written a bus device driver
>> which itself is a pci driver. Child devices
>> may allocate resources from my bus device.
>>
>> My bus device does the usual
>> management of resources through
>> the children's ivars.
>>
>> My question is this:
>>
>> The bus device mallocs the
>> children's ivars in bus_add_child
>> and frees the ivars in either
>> bus_detach or bus_child_detached.
>>
>> The children are added in identify
>> methods through BUS_ADD_CHILD.
>>
>> As I understand the code the bus device's
>> bus_child_detached method is called
>> in device_delete_child only if
>> the child device is already attached.
>>
>> So, there seems to be a memory leak if
>> I delete the child device in either
>> identify or probe.
>>
>> My current solution (not tested yet) is to
>> explicitly call BUS_CHILD_DETACHED
>> in the child device's code before
>> calling device_delete_child.
>>
>> Is this the correct way or is
>> there a more elegant/cleaner solution?
>>
>> I expected to find something like a
>> BUS_DELETE_CHILD method.
>
> We should perhaps have a BUS_CHILD_DELETED? I think that would do what you
> want. We could maybe add a BUS_DELETE_CHILD(), but it would be assymmetric to
> have device_delete_child() call BUS_DELETE_CHILD() when device_add_child()
> does not call BUS_ADD_CHILD(). (Instead, BUS_ADD_CHILD() calls
> device_add_child, which is perhaps wrong.)
>
> For now I would change your child code to call a wrapper foo_delete_child()
> function from your child drivers directly rather than calling
> device_delete_child(). foo_delete_child() can do its cleanup and then call
> device_delete_child().
We likely should have a BUS_CHILD_DELETED function that can get called for each class in the stack when a child is deleted so you can remove the ivars. The ivars should likely stay around when the device is merely detached.
Warner
More information about the freebsd-hackers
mailing list