| |||||||||||||
A simplified IDR APIA simplified IDR APIPosted Feb 7, 2013 9:21 UTC (Thu) by amonnet (subscriber, #54852)Parent article: A simplified IDR API
IDR jobs is to allocate both memory and a unique identifier, true ?
I don't undestand why memory allocation does not fall on the caller side as usual.
+++
(Log in to post comments)
A simplified IDR API Posted Feb 7, 2013 14:21 UTC (Thu) by corbet (editor, #1) [Link] 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.
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.
|
|||||||||||||