All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martyn Welch <martyn.welch@ge.com>
To: "Emilio G. Cota" <cota@braap.org>
Cc: gregkh@suse.de, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/8] staging: vme: add functions for bridge module refcounting
Date: Mon, 08 Aug 2011 09:01:46 +0100	[thread overview]
Message-ID: <4E3F97EA.2020600@ge.com> (raw)
In-Reply-To: <20110805174728.GA1741@flamenco.cs.columbia.edu>

On 05/08/11 18:47, Emilio G. Cota wrote:
> On Fri, Aug 05, 2011 at 10:24:55 +0100, Martyn Welch wrote:
>> I think that by refcounting the resources being used we
>> will know whether a bridge module is being used or not,
>> thus whether it can be unloaded or not.
> 
> But the granularity is wrong; if you want to know whether the
> bridge is being used, just keep track of the devices *which
> want to make known* that they're under the bridge.
> 

I disagree, it shouldn't be up to the driver to determine whether it's use of
the bus should be known by the system. The system should know when the bus is
being used.

>> By reference counting the use of resources we minimise the
>> chance of poorly written drivers using resources, but not
>> registering the fact that they are in fact using a VME bridge.
> 
> A driver leaking a resource will then leave a bogus refcount
> on the bus driver--a clear case of self-inflicted pain.
> 

As opposed to adding a function that *only* refcounts and therefore requires
every driver to make extra explicit function call just to keep the refcounts
up-to-date.

> The argument of "poorly written drivers" does not apply;
> I would expect all the merged drivers to be "good quality"
> only, that's why we want to be upstream and why we put effort
> in reviewing. Your point is well-intentioned, but in
> practice we'd be shooting ourselves in the foot, potentially
> ending up with an unremovable vme bridge module--which is
> worse than a driver leaking a resource.
> 

Which wouldn't happen because all the upstreamed drivers are "good quality". I
might add that failing to free a resource will mean that it won't be
re-allocated, so having visibility of the number of resources having been
allocated would be advantageous.

> Refcounting must be kept simple & stupid; doing it behind the
> backs of the drivers we're trying to protect is a mistake.
> 

I just simply disagree. Forcing each driver to specifically maintain the
refcount is just stupid when an alternative is possible.

Martyn

-- 
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms                   | Wales (3828642) at 100
T +44(0)127322748                          | Barbirolli Square, Manchester,
E martyn.welch@ge.com                      | M2 3AB  VAT:GB 927559189

  reply	other threads:[~2011-08-08  8:01 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-01 10:20 [PATCH 0/8] VME Driver Fixes Manohar Vanga
2011-08-01 10:20 ` [PATCH 1/8] staging: vme_user: change kmalloc+memset to kzalloc Manohar Vanga
2011-08-01 10:52   ` Martyn Welch
2011-08-10  7:44     ` Martyn Welch
2011-08-01 10:20 ` [PATCH 2/8] staging: vme: allow explicit assignment of bus numbers Manohar Vanga
2011-08-01 11:10   ` Dan Carpenter
2011-08-01 12:12     ` Manohar Vanga
2011-08-01 13:06   ` Martyn Welch
2011-08-01 14:31     ` Manohar Vanga
2011-08-01 15:50       ` Martyn Welch
2011-08-02 11:54         ` Manohar Vanga
2011-08-02 14:57           ` Martyn Welch
2011-08-03  8:54             ` Martyn Welch
2011-08-04  9:16               ` Manohar Vanga
2011-08-01 10:20 ` [PATCH 3/8] staging: vme: make [alloc|free]_consistent bridge specific Manohar Vanga
2011-08-01 11:10   ` Dan Carpenter
2011-08-01 12:24     ` Manohar Vanga
2011-08-01 13:41   ` Martyn Welch
2011-08-01 13:40     ` Manohar Vanga
2011-08-01 14:00     ` Manohar Vanga
2011-08-01 14:05       ` Martyn Welch
2011-08-01 10:20 ` [PATCH 4/8] staging: vme: keep track of registered buses Manohar Vanga
2011-08-01 10:20 ` [PATCH 5/8] staging: vme: add functions for bridge module refcounting Manohar Vanga
2011-08-03 14:04   ` Martyn Welch
2011-08-03 14:06     ` Manohar Vanga
2011-08-03 15:23       ` Emilio G. Cota
2011-08-04  7:23         ` Martyn Welch
2011-08-04 16:34           ` Emilio G. Cota
2011-08-05  7:45             ` Martyn Welch
2011-08-05  9:04               ` Manohar Vanga
2011-08-05  9:24                 ` Martyn Welch
2011-08-05 17:47                   ` Emilio G. Cota
2011-08-08  8:01                     ` Martyn Welch [this message]
2011-08-08  9:14                       ` Emilio G. Cota
2011-08-08  9:42                         ` Martyn Welch
     [not found]                         ` <4E3FABDA.8080204@ge.com>
     [not found]                           ` <20110808101140.GA21300@flamenco.cs.columbia.edu>
2011-08-08 11:06                             ` Martyn Welch
2011-08-08 17:22                               ` Emilio G. Cota
2011-08-08 18:04                                 ` Greg KH
2011-08-09  9:00                                 ` Martyn Welch
2011-08-09 19:19                                   ` Emilio G. Cota
2011-08-10  7:39                                     ` Martyn Welch
2011-08-10  9:15                                       ` Emilio G. Cota
2011-08-10  9:50                                         ` Martyn Welch
2011-08-10 18:35                                           ` Emilio G. Cota
2011-08-09 13:24                   ` Manohar Vanga
2011-08-09 14:26                     ` Martyn Welch
2011-08-09 14:35                       ` Manohar Vanga
2011-08-09 15:05                         ` Martyn Welch
2011-08-09 18:49                       ` Emilio G. Cota
2011-08-10  6:52                         ` Manohar Vanga
2011-08-01 10:20 ` [PATCH 6/8] staging: vme: rename *_slot_get to *_get_slot Manohar Vanga
2011-08-01 12:29   ` Martyn Welch
2011-08-01 12:31     ` Manohar Vanga
2011-08-09 15:18       ` Martyn Welch
2011-08-09 15:25         ` Greg KH
2011-08-09 15:32         ` Manohar Vanga
2011-08-01 10:20 ` [PATCH 7/8] staging: vme: add struct vme_dev for VME devices Manohar Vanga
2011-08-09 15:19   ` Martyn Welch
2011-08-01 10:20 ` [PATCH 8/8] staging: vme: make match() driver specific to improve non-VME64x support Manohar Vanga
2011-08-03  9:16   ` Martyn Welch
2011-08-03 12:18     ` Manohar Vanga
2011-08-01 14:29 ` [PATCH 0/8] VME Driver Fixes Martyn Welch
2011-08-01 14:32   ` Manohar Vanga
2011-08-23 22:07 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E3F97EA.2020600@ge.com \
    --to=martyn.welch@ge.com \
    --cc=cota@braap.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.