Cornelia Huck wrote:
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo <[email protected]> wrote:
It's debatable but I think things will be safer this way. If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing problem when
something goes wrong, which is better than silent object leaking and/or
jumping to non-existent address way later.
I agree that oopsing is bad. However, lingering references are not
always coding errors. What if it will just take long for a reference to
be given up? You'd have a hanging device_unregister(), with no
particular gain.
It's more like future plan than immediately applicable. I think most
high-level driver related interfaces can be converted as sysfs was
converted such that they disconnect immediately from the device -
resolving conflicts between higher layer using reference counts and
device driver layer which expects immediate disconnect is responsibility
of those interfaces - just as sysfs does it.
If you have lingering reference to struct device after driver is
detached, you're already screwed. If there's outstanding reference to
it from the previous driver, how are you gonna load the next one?
You're gonna have to wait somewhere for all the references to go away.
Actually, your patch series is doing exactly this during module
unloading. Problem is that you'll need to do the same thing before
attaching the next driver for the same device.
Immediate-disconnect from all higher interface for device drivers is my
goal for driver model as I wrote in the RFD about lifetime rules. I
think it's doable and should result in easier model to get right, but I
might be missing something big time, so please point out if you can spot
holes or don't agree.
I personally think all driver interface should be made this way such
that completion of unregister function guarantees no further access to
the object or module. IMHO, it's more intuitive and easier to force
correctness.
If we really did this, we should also provide a non-waiting alternative.
For transitional purpose, sure. In the long term, I think it's better
if we can do without it.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
