> I much prefer this, as I would like to see it eventually, but I'd rather
> see the implications worked out before it's generalized.
Then I have to be concerned about parts of the driver model removing
parents of my devices without my knowing it. Didn't PCI already go
through this problem with bus's being removed?
If my PCI devices gets removed, it simply calls my PCI callbacks, but
then my PCI drivers have to link into the core and call remove on all
the host devices, then node devices, then unit directories. All this has
to happen manually, and it puts the burden all the way down the tree,
when it should remain only in the bus.
It also does not help the case where something emulates an IEEE-1394
node on the locally handled bus. If it creates a node, and then behind
that, creates unit directories, and then attaches some other sort of
children unknown to the ieee1394 core. There's no possible way that
device can safely be removed by the ieee1394 core. So then I have to
export all sorts of extra functionality to provide the same thing this
2 line callback can do.
I'm not sure what the problem is in allowing the bus driver to know when
a device is about to be removed for some reason. At the very least it
makes for a good sanity check mechanism.
-- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:22 EST