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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
