mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ben Collins <bcollins@debian.org>
To: Greg KH <greg@kroah.com>
Cc: Patrick Mochel <mochel@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH] Device removal callback
Date: Sun, 9 Mar 2003 20:02:32 -0500	[thread overview]
Message-ID: <20030310010232.GB16134@phunnypharm.org> (raw)
In-Reply-To: <20030310001102.GE6082@kroah.com>

On Sun, Mar 09, 2003 at 04:11:02PM -0800, Greg KH wrote:
> On Sun, Mar 09, 2003 at 01:14:13PM -0500, Ben Collins wrote:
> > 
> > So I added a new callback to the device stucture called remove. This
> > callback is done when device_del is about to remove a device from the
> > tree. I've used this internally to make sure I can walk the list of
> > children myself, and also do some other cleanups.
> 
> But don't you really want to remove the children before you remove the
> parent?  If you do this patch, then the remove() function will have to
> clean up the children first, right?  Can we handle the core recursion
> with the current locks properly?

Actually, with this patch, the dev->remove(dev) is called before the
driver model does any cleanup. So you can cleanup children at that
point, and the parent device is still sane.

The reason for this is I would like to be able to unregister a node's
device from several places without worrying about other things that need
to be done. One call.

> Yes, for USB we still have a list of a device's children, as we need
> them for various things, and the current driver model only has a parent
> pointer, not a child pointer (which is good, as for USB we can have
> multiple children).  So in the function where we know a USB device is
> disconnected, we walk our list of children and disconnect them in a
> depth-first order.  With this patch I don't see how it helps me push
> code into the driver core.

I haven't looked into USB in depth, but consider this. Without the
patch, to cleanup a device:

void ieee1394_remove_node(struct node_entry *ne)
{
	...

	list_for_each(..., &ne->device.children) {
		device_unregister(list_to_dev(lh));
	}

	device_unregister(&ne->device);
}


Then to remove a device, this function must always be called, so that
the unit-directories get removed. What happens if the PCI bus gets
yanked out from underneath us? How does the OHCI card's callbacks get me
back down to this point? Without a lot of extra infrastructure, the
nodes and unit directories get left hanging.

Instead I now do this, with the patch.

void ieee1394_remove_node(struct device *dev)
{
	list_for_each(..., &ne->device.children) {
		device_unregister(list_to_dev(lh));
	}
}

...
	/* Where the dev is created */
	...
	ne->device.remove = ieee1394_remove_node;
	device_register(&ne->device);

Now, no matter where it's called from, doing...

	device_unregister(&ne->device);

...will make sure my remove callback is executed, so the children
devices get unregistered aswell. I extend this to the host device
and I have a recursive remocal scheme that is safe no matter where my
devices get unregistered. Whole lot simpler that adding in a lot of
failsafe's and checks.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

  reply	other threads:[~2003-03-10  0:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-09 18:14 Ben Collins
2003-03-10  0:11 ` Greg KH
2003-03-10  1:02   ` Ben Collins [this message]
2003-03-10 15:59     ` Patrick Mochel
2003-03-10 16:55       ` Ben Collins
2003-03-10 17:21         ` Greg KH
2003-03-10 18:12           ` Ben Collins
2003-03-10 15:45 ` Patrick Mochel
2003-03-10 16:30   ` Ben Collins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030310010232.GB16134@phunnypharm.org \
    --to=bcollins@debian.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®