From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Hajda Subject: Re: [RFC 1/2] core: Add generic object registry implementation Date: Fri, 07 Nov 2014 10:10:41 +0100 Message-ID: <545C8C91.3000703@samsung.com> References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.com> <545A19C8.6090508@samsung.com> <20141105140418.GA18067@ulmo> <545A49AF.9080901@samsung.com> <20141106094820.GH26297@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by gabe.freedesktop.org (Postfix) with ESMTP id 2A0116F114 for ; Fri, 7 Nov 2014 01:10:47 -0800 (PST) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NEN007A3WALNY80@mailout2.w1.samsung.com> for dri-devel@lists.freedesktop.org; Fri, 07 Nov 2014 09:13:33 +0000 (GMT) In-reply-to: <20141106094820.GH26297@ulmo> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter List-Id: dri-devel@lists.freedesktop.org T24gMTEvMDYvMjAxNCAxMDo0OCBBTSwgVGhpZXJyeSBSZWRpbmcgd3JvdGU6Cj4gT24gV2VkLCBO b3YgMDUsIDIwMTQgYXQgMDU6MDA6NDdQTSArMDEwMCwgQW5kcnplaiBIYWpkYSB3cm90ZToKPj4g T24gMTEvMDUvMjAxNCAwMzowNCBQTSwgVGhpZXJyeSBSZWRpbmcgd3JvdGU6Cj4+PiBPbiBXZWQs IE5vdiAwNSwgMjAxNCBhdCAwMTozNjoyNFBNICswMTAwLCBBbmRyemVqIEhhamRhIHdyb3RlOgo+ Pj4+IE9uIDExLzA0LzIwMTQgMDU6MjkgUE0sIFRoaWVycnkgUmVkaW5nIHdyb3RlOgo+Pj4+PiBG cm9tOiBUaGllcnJ5IFJlZGluZyA8dHJlZGluZ0BudmlkaWEuY29tPgo+Pj4+Pgo+Pj4+PiBBZGQg YSBnZW5lcmljIGltcGxlbWVudGF0aW9uIG9mIGFuIG9iamVjdCByZWdpc3RyeS4gVGhpcyB0YXJn ZXRzIGRyaXZlcnMKPj4+Pj4gYW5kIHN1YnN5c3RlbXMgdGhhdCBwcm92aWRlIGF1eGlsaWFyeSBv YmplY3RzIHRoYXQgb3RoZXIgZHJpdmVycyBuZWVkIHRvCj4+Pj4+IGxvb2sgdXAuIFRoZSBnb2Fs IGlzIHRvIHB1dCB0aGUgZGlmZmljdWx0IHBhcnRzIChrZWVwIG9iamVjdCByZWZlcmVuY2VzLAo+ Pj4+PiBtb2R1bGUgdXNhZ2UgY291bnQsIC4uLikgaW50byBjb3JlIGNvZGUgc28gdGhhdCBpbmRp dmlkdWFsIHN1YnN5c3RlbXMgZG8KPj4+Pj4gbm90IGhhdmUgdG8gZGVhbCB3aXRoIHRoZW0uCj4+ Pj4+Cj4+Pj4+IFRoZSBpbnRlbnRpb24gaXMgZm9yIHN1YnN5c3RlbXMgdG8gaW5zdGFudGlhdGUg YSBzdHJ1Y3QgcmVnaXN0cnkgYW5kIHVzZQo+Pj4+PiBhIHN0cnVjdCByZWdpc3RyeV9yZWNvcmQg ZW1iZWRkZWQgaW50byBhIHN1YnN5c3RlbS1zcGVjaWZpYyBzdHJ1Y3R1cmUgdG8KPj4+Pj4gcHJv dmlkZSBhIHN1YnN5c3RlbS1zcGVjaWZpYyBBUEkgYXJvdW5kIHRoYXQuCj4+Pj4KPj4+Pgo+Pj4+ IEFzIEkgdW5kZXJzdGFuZCB5b3Ugd2FudCB0byB1c2UgdGhpcyByZWdpc3RyeSBmb3IgcGFuZWxz IGFuZCBicmlkZ2VzLgo+Pj4+IENvdWxkIHlvdSBleHBsYWluIHRoZSBpZGVhIGFuZCBkZXNjcmli ZSBleGFtcGxlIHNjZW5hcmlvIHdoZW4gdGhlc2UKPj4+PiByZWZjb3VudGluZ3MgYXJlIHVzZWZ1 bC4gSSBndWVzcyBpdCBzaG91bGQgYmUgd2hlbiBwYW5lbCBhdHRhY2hlZCB0bwo+Pj4+IGRybWRy diB3YW50IHRvIGRpc2FwcGVhci4KPj4+Cj4+PiBDb3JyZWN0LiBXaGVuIGEgcGFuZWwgZHJpdmVy IGlzIHVubG9hZGVkIGl0IGZyZWVzIG1lbW9yeSBhc3NvY2lhdGVkIHdpdGgKPj4+IHRoZSBwYW5l bC4gVGhlIGdvYWwgb2YgdGhpcyByZWdpc3RyeSBpcyBmb3IgdGhlIHBhbmVsIG9iamVjdCB0byBz dGF5Cj4+PiBhcm91bmQgdW50aWwgYWxsIHJlZmVyZW5jZXMgYXJlIGdvbmUuCj4+Pgo+Pj4+IFJl YWwgbGlmZXRpbWUgb2YgcGFuZWwgaXMgbGltaXRlZCBieSBwcm9iZS9yZW1vdmUgY2FsbGJhY2tz IG9mIHBhbmVsCj4+Pj4gZHJpdmVyLCBkbyB5b3Ugd2FudCB0byBwcm9sb25nIGl0IGJlaGluZCB0 aGVzZSBsaW1pdHM/Cj4+Pgo+Pj4gWWVzLgo+Pj4KPj4+PiBEbyB5b3Ugd2FudCB0byBoYXZlIHpv bWJpZSBwYW5lbHMsIHdpdGhvdXQgaGFyZHdhcmUgdGhleSBhYnN0cmFjdD8gRm9yCj4+Pj4gd2hh dCBwdXJwb3NlPwo+Pj4KPj4+IFNvIHRoYXQgZGlzcGxheSBkcml2ZXJzIGRvbid0IHRyeSB0byBh Y2Nlc3Mgb2JqZWN0cyB0aGF0IGhhdmUgYmVlbgo+Pj4gZnJlZWQuCj4+Cj4+IFdoeSBkbyBub3Qg anVzdCByZWxlYXNlIHBhbmVsIHJlZmVyZW5jZXMgZnJvbSBkcm1fZGV2LCBJIGhhdmUKPj4gc3Vj Y2Vzc2Z1bGx5IGltcGxlbWVudGVkIGRzaSBwYW5lbHMgdGhpcyB3YXksIHRoYW5rcyB0byBkc2kg YnVzIHNwZWNpZmljCj4+IGF0dGFjaC9kZXRhY2ggY2FsbGJhY2tzIGFuZCBkcm0gaG90cGx1ZyBt ZWNoYW5zaW0uCj4gCj4gTGlrZSB5b3Ugc2F5IHlvdXJzZWxmLCB0aGF0J3Mgc29tZXRoaW5nIHRo YXQgd29yayBvbmx5IGZvciBEU0kuIEFueQo+IG90aGVyIHR5cGUgb2YgcGFuZWwgY2FuJ3QgZG8g dGhpcy4KCkJ1dCBpdCBtZWFucyB0aGF0IGlmIHdlIHdhbnQgdG8gbWFrZSBwYW5lbHMgc2FmZSB3 ZSBqdXN0IG5lZWQgYWRkCnJlZ2lzdHJhdGlvbi9kZXJlZ2lzdHJhdGlvbiBub3RpZmljYXRpb25z IHRvIHBhbmVscywgbm90aGluZyBtb3JlLgoKCj4gCj4+IE15IHBvaW50IGlzIHdlIGRvIG5vdCBu ZWVkIHRvIG1ha2UgdGhlIHdob2xlIHRyaWNreSBkb3VibGUgcmVmY291bnRpbmcsCj4gCj4gVGhl cmUncyBubyBkb3VibGUgcmVmY291bnRpbmcuIFdlIGhhdmUgbm8gcmVmY291bnRpbmcgYXQgYWxs IGF0IHRoZQo+IG1vbWVudC4KCkZvciBtZSByZWdpc3RyeV9yZWNvcmQua3JlZiBhbmQgdHJ5X21v ZHVsZV9nZXQgc291bmRzIGxpa2UgcmVmY291bnRpbmcuCgo+IAo+PiB3aXRoIHRvdGFsIHJlZGVz aWduIG9mIHBhbmVscywgcmV2b2tlLCB6b21iaWVzLCBldGMuLi4uIEl0IGlzIGVub3VnaCB0bwo+ IAo+IEl0J3Mgbm90IGEgdG90YWwgcmVkZXNpZ24uIEl0IGp1c3QgbWFrZXMgaXQgbW9yZSBtYXR1 cmUgYW5kIGltcGxlbWVudHMKPiBmZWF0dXJlcyB0aGF0IEkgdGhpbmsgYXJlIHVzZWZ1bCAoYW5k IG5lZWRlZCkgYnV0IHRoYXQgd2VyZSBsZWZ0IG91dCBmb3IKPiB0aGUgc2FrZSBvZiBzaW1wbGlj aXR5LiBOb3cgaXQgdHVybnMgb3V0IHRoYXQgdGhpcyBpcyBhY3R1YWxseSBxdWl0ZQo+IGZyYWdp bGUgYW5kIGVhc3kgdG8gZ2V0IHdyb25nLgoKQW5kIEkgdHJ5IHRvIGNvbnZpbmNlIHlvdSB3ZSBj YW4gc3RpbGwga2VlcCBzaW1wbGljaXR5IGFuZCBtYWtlIGl0IHNhZmUuCgo+IAo+PiBoYXZlIGp1 c3QgaG90IHBsdWcvdW5wbHVnIGNhbGxiYWNrcy4gVGhpcyBpcyB3aHkgSSBoYXZlIHByb3Bvc2Vk IGZldwo+PiBtb250aHMgYWdvIGludGVyZmFjZV90cmFja2VyIGZyYW1ld29yay4gSXQgY2FuIGFk ZCBob3QodW4pcGx1Zwo+PiBjYXBhYmlsaXR5IGluIGEgZ2VuZXJpYyB3YXkgdG8gYW55IGZyYW1l d29yay4KPiAKPiBUaGF0J3Mgc29tZXRoaW5nIHRoYXQgdGhpcyBvYmplY3QgcmVnaXN0cnkgY291 bGQgZWFzaWx5IGltcGxlbWVudCBhcwo+IHdlbGwuIEJ1dCBpbnN0ZWFkIG9mIHBhc3NpbmcgYXJv dW5kIHZvaWQgKiBhbmQgdHlwZSBJRHMgYXMgaW4gdGhlCj4gaW50ZXJmYWNlIHRyYWNrZXIgaXQg Y291bGQgZGVhbCB3aXRoIHJlYWwgb2JqZWN0cyBmb3IgcHJvcGVyIHR5cGUtCj4gc2FmZXR5LgoK SXQgaXMgbm90IGEgcHJvYmxlbSB0byBhZGQgdHlwZS1zYWZlIGhlbHBlcnMgdG8gaW50ZXJmYWNl IHRyYWNrZXIuCgpSZWdhcmRzCkFuZHJ6ZWoKCj4gCj4gVGhpZXJyeQo+IAo+IAo+IAo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gZHJpLWRldmVsIG1h aWxpbmcgbGlzdAo+IGRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKPiBodHRwOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCj4gCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGlu ZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVk ZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751534AbaKGJLD (ORCPT ); Fri, 7 Nov 2014 04:11:03 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:18503 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbaKGJKs (ORCPT ); Fri, 7 Nov 2014 04:10:48 -0500 X-AuditID: cbfec7f4-b7f6c6d00000120b-41-545c8c940c81 Message-id: <545C8C91.3000703@samsung.com> Date: Fri, 07 Nov 2014 10:10:41 +0100 From: Andrzej Hajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-version: 1.0 Newsgroups: gmane.comp.video.dri.devel,gmane.linux.kernel To: Thierry Reding Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter Subject: Re: [RFC 1/2] core: Add generic object registry implementation References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.com> <545A19C8.6090508@samsung.com> <20141105140418.GA18067@ulmo> <545A49AF.9080901@samsung.com> <20141106094820.GH26297@ulmo> In-reply-to: <20141106094820.GH26297@ulmo> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsVy+t/xq7pTemJCDE42WVksfHiX2eLK1/ds Fs2L17NZXN41h83i5655LA6sHnu/LWDx2DnrLrvH/rlr2D3udx9n8vi8SS6ANYrLJiU1J7Ms tUjfLoErY8OiD8wFr6Urds/7w9TAuEGsi5GTQ0LARGLv/V3MELaYxIV769m6GLk4hASWMkr0 HWtjhHA+MUr8+beNFaSKV0BLYuaCBUAdHBwsAqoSi7cWgYTZBDQl/m6+yQZiiwpESFxZM4cR olxQ4sfkeywgNp+ApcSxJZ3sILaIgK7E/9NvWEDmMwvMY5TYd/gBWJGwgLvEvZXXoBYfY5SY eXsdWIITaPGC1QdYQBYzC6hLTJmSCxJmFpCX2LzmLfMERsFZSPbNQqiahaRqASPzKkbR1NLk guKk9FxDveLE3OLSvHS95PzcTYyQQP+yg3HxMatDjAIcjEo8vJ1CMSFCrIllxZW5hxglOJiV RHhTG4FCvCmJlVWpRfnxRaU5qcWHGJk4OKUaGGepRYpUSVbc3CB48/LrSpOgeZ9yli5/nKfi 0BBjEF7BqRW4Ia7kcX3Kh2/Ou9lq7I7yl//hZq2q2b1tQd+NbT+uZyx+avrDRj3izsWnVVE5 X22Xtk80vmg881eC7Fv1iNAf5etVFH/e9xC2v9a1ZZfd8eMVTs0BzTEZ/4pO+wlXvy/kC+ff pcRSnJFoqMVcVJwIAIeRx39SAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/06/2014 10:48 AM, Thierry Reding wrote: > On Wed, Nov 05, 2014 at 05:00:47PM +0100, Andrzej Hajda wrote: >> On 11/05/2014 03:04 PM, Thierry Reding wrote: >>> On Wed, Nov 05, 2014 at 01:36:24PM +0100, Andrzej Hajda wrote: >>>> On 11/04/2014 05:29 PM, Thierry Reding wrote: >>>>> From: Thierry Reding >>>>> >>>>> Add a generic implementation of an object registry. This targets drivers >>>>> and subsystems that provide auxiliary objects that other drivers need to >>>>> look up. The goal is to put the difficult parts (keep object references, >>>>> module usage count, ...) into core code so that individual subsystems do >>>>> not have to deal with them. >>>>> >>>>> The intention is for subsystems to instantiate a struct registry and use >>>>> a struct registry_record embedded into a subsystem-specific structure to >>>>> provide a subsystem-specific API around that. >>>> >>>> >>>> As I understand you want to use this registry for panels and bridges. >>>> Could you explain the idea and describe example scenario when these >>>> refcountings are useful. I guess it should be when panel attached to >>>> drmdrv want to disappear. >>> >>> Correct. When a panel driver is unloaded it frees memory associated with >>> the panel. The goal of this registry is for the panel object to stay >>> around until all references are gone. >>> >>>> Real lifetime of panel is limited by probe/remove callbacks of panel >>>> driver, do you want to prolong it behind these limits? >>> >>> Yes. >>> >>>> Do you want to have zombie panels, without hardware they abstract? For >>>> what purpose? >>> >>> So that display drivers don't try to access objects that have been >>> freed. >> >> Why do not just release panel references from drm_dev, I have >> successfully implemented dsi panels this way, thanks to dsi bus specific >> attach/detach callbacks and drm hotplug mechansim. > > Like you say yourself, that's something that work only for DSI. Any > other type of panel can't do this. But it means that if we want to make panels safe we just need add registration/deregistration notifications to panels, nothing more. > >> My point is we do not need to make the whole tricky double refcounting, > > There's no double refcounting. We have no refcounting at all at the > moment. For me registry_record.kref and try_module_get sounds like refcounting. > >> with total redesign of panels, revoke, zombies, etc.... It is enough to > > It's not a total redesign. It just makes it more mature and implements > features that I think are useful (and needed) but that were left out for > the sake of simplicity. Now it turns out that this is actually quite > fragile and easy to get wrong. And I try to convince you we can still keep simplicity and make it safe. > >> have just hot plug/unplug callbacks. This is why I have proposed few >> months ago interface_tracker framework. It can add hot(un)plug >> capability in a generic way to any framework. > > That's something that this object registry could easily implement as > well. But instead of passing around void * and type IDs as in the > interface tracker it could deal with real objects for proper type- > safety. It is not a problem to add type-safe helpers to interface tracker. Regards Andrzej > > Thierry > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >