On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote: > > Given that I've mucked around in drm_mm quite a bit I'd be very interested > > in your opinion about what's weird in it (and presumably what could be > > improved). Can you elaborate? > > Mostly the API, which is also somewhat poorly documented. I've not dug > into the internals beyond trying to figure out how to use it. Looking at > the users the API is non-obvious, the interface involves a mix of calls > and digging deep into struct internals. Well, I've rewritten the api but that transition is not yet complete, i.e. the new interface is there, but no driver is converted yet. The old api has a two-step allocation (search_free + get_block) and frees allocated ranges with put_block. The new api has just insert_node and remove_node, struct drm_mm_node must be allocated by the caller (to get rid of the racy preallocation scheme and allow embedding of drm_mm_node). There's also the lru scanning helpers (only used by intel). Under specific conditions (should be all documented in comments) this can be used as an eviction roaster. Generally only node->start should be used by drivers, otherwise drm_mm_node should be opaque. At least that's the idea. btw, old conversion patches for i915 to the new interface are at: http://cgit.freedesktop.org/~danvet/drm/log/?h=embed-gtt-space When creating the new interfaces I've tried to document them. Ideas to improve that highly welcome. > I'd have expected an API that had allocate/free type methods and exposed > the needed information directly or very easily not one that has drivers > doing. drm_sman seems to be attempt in that direction but its also rather > odd with interfaces like Should be fixed, see above ;-) [snip] > Possibly drm_sman and friends should just wrap whatever simple native > allocator exists on the OS ? Well, drm_mm has some graphics specific magic (range restricted scans and the eviction helpers). But simpler stuff like sman is imo just "drm likes to reinvent the wheel". Unfortunately I don't have the hw, so I haven't dared to touch it (the snippet you've posted is a prime example why). Yours, Daniel -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
