| |||||||||||||
A simplified IDR APIA simplified IDR APIPosted Feb 7, 2013 14:21 UTC (Thu) by corbet (editor, #1)In reply to: A simplified IDR API by amonnet Parent article: A simplified IDR API IDR has to allocate memory for IDR's internal record keeping; there is a radix-tree like structure for fast lookups and traversal. The caller doesn't (and shouldn't) know about that structure, so it cannot allocate it.
(Log in to post comments)
A simplified IDR API Posted Feb 7, 2013 14:49 UTC (Thu) by amonnet (subscriber, #54852) [Link]
Second (stupid?) question : why not provide the second call a reference to the allocated memory from the first one ? And forget the preemption deactivation dance that some (RT people) dislike ?
A simplified IDR API Posted Feb 7, 2013 14:55 UTC (Thu) by corbet (editor, #1) [Link] Not stupid. The relevant code is (usually) about to go under spinlock anyway, so the preemption disable isn't as big a deal as it could be. An API like you suggest could maybe work; one could also maybe split it into:
id = idr_allocate_id(gfp_flags); /* non-atomic context */
idr_assign_id(id, pointer); /* Can be atomic */
That would handle the atomic association of the ID with the pointer while under lock without per-CPU stuff, but would require the IDR library to manage assigned-but-not-active IDs. With either this idea or yours, there would also have to be an idr_never_mind() function to back things out if need be.
|
|||||||||||||