On Wed, Apr 23, 2008 at 03:36:19PM +0200, Andrea Arcangeli wrote:
I said I could test without it. It is needed for the final version.
It also makes the API consistent. What you are proposing is equivalent
to having a file you can open but never close.
This whole discussion seems ludicrous. You could refactor the code to get
the sorted list of locks, pass that list into mm_lock to do the locking,
do the register/unregister, then pass the same list into mm_unlock.
If the allocation fails, you could fall back to the older slower method
of repeatedly scanning the lists and acquiring locks in ascending order.
If you are not going to provide the _unregister callout you need to change
the API so I can scan the list of notifiers to see if my structures are
already registered.
We register our notifier structure at device open time. If we receive a
_release callout, we mark our structure as unregistered. At device close
time, if we have not been unregistered, we call _unregister. If you
take away _unregister, I have an xpmem kernel structure in use _AFTER_
the device is closed with no indication that the process is using it.
In that case, I need to get an extra reference to the module in my device
open method and hold that reference until the _release callout.
Additionally, if the users program reopens the device, I need to scan the
mmu_notifiers list to see if this tasks notifier is already registered.
I view _unregister as essential. Did I miss something?
Thanks,
Robin
--
