LWN: Comments on "A simplified IDR API"

A simplified IDR API

dmk — 2013-02-09T15:42:49+00:00

If you need to pair some calls, and the second one has an _end() suffix,
you damn well need the _begin() suffix on the first one.

Everything else is confusing.

A simplified IDR API

corbet — 2013-02-07T14:55:40+00:00

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.

A simplified IDR API

amonnet — 2013-02-07T14:49:50+00:00

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

corbet — 2013-02-07T14:21:47+00:00

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

amonnet — 2013-02-07T09:21:33+00:00

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.

+++