All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ram Pai <linuxram@us.ibm.com>
Cc: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, yinghai@kernel.org,
	bhutchings@solarflare.com, socketcan@hartkopp.net,
	bhelgaas@google.com, linux@dominikbrodowski.net
Subject: Re: [PATCH 0/5 v2] PCI: fix cardbus and sriov regressions
Date: Sun, 3 Jul 2011 14:30:00 -0700	[thread overview]
Message-ID: <CA+55aFwo-48yKu+raRF3B9n1mqd1qV35eDq56Yi+erPygkuTvA@mail.gmail.com> (raw)
In-Reply-To: <1309477662-18680-1-git-send-email-linuxram@us.ibm.com>

Gaah. I'm still rather uncomfortable about this, and I wonder about
patch 2 in particular. It seems that that patch could/should be split
up: the whole change to "find_resource()" etc looks like prime
material for a separate patch that splits up that function and
explains why that change is done.

Also, quite frankly, by the time you pass in eight different arguments
(and pretty complex ones at that, with one being the alignment
function pointer), I start thinking that you should have passed in a
pointer to a descriptor structure instead. I get the feeling that the
"resource requirements" really should be a structure instead of lots
of individual arguments:

IOW, this part:

+                     resource_size_t newsize, resource_size_t min,
+                     resource_size_t max, resource_size_t align,
+                     resource_size_t (*alignf)(void *,
+                                               const struct resource *,
+                                               resource_size_t,
+                                               resource_size_t),
+                     void *alignf_data)

really makes me go

   struct resource_requirement {
      resource_size_t min, max, align;
      resource_size_t (*alignf)(const struct resource *, struct
resource_requirement *);
      void *alignf_data);
   };

and I'd really change the function argument to take that kind of
simplified thing instead.

And that cleanup/re-organization would be prime material for a totally
independent patch that changes no semantics at all, just prepares for
the other changes.

That way the final "patch 2" would be smaller and do the semantic
changes, instead of being a mix of semantic changes and infrastructure
changes.

And some of the cleanup stuff I could merge for 3.0 just to make things easier.

Hmm?

                 Linus

  parent reply	other threads:[~2011-07-03 21:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 23:47 [PATCH 0/5 v2] PCI: fix cardbus and sriov regressions Ram Pai
2011-06-30 23:47 ` [PATCH 1/5 v2] PCI: honor child buses optional size in hot plug configuration Ram Pai
2011-06-30 23:47 ` [PATCH 2/5 v2] PCI : ability to relocate assigned pci-resources Ram Pai
2011-06-30 23:47 ` [PATCH 3/5 v2] PCI: make SRIOV resources optional Ram Pai
2011-07-01  6:01   ` Oliver Hartkopp
2011-07-06 17:48     ` Jesse Barnes
2011-07-07 15:34       ` Oliver Hartkopp
2011-06-30 23:47 ` [PATCH 4/5 v2] PCI: make cardbus-bridge " Ram Pai
2011-06-30 23:47 ` [PATCH 5/5 v2] PCI: code and terminology cleanup Ram Pai
2011-07-01 23:07 ` [PATCH 0/5 v2] PCI: fix cardbus and sriov regressions Ben Hutchings
2011-07-02 13:04   ` Ram Pai
2011-07-04 23:35     ` Ben Hutchings
2011-07-03 21:30 ` Linus Torvalds [this message]
2011-07-04  3:55   ` Harry Wei
2011-07-06  8:53   ` Ram Pai
2011-07-06 17:46     ` Jesse Barnes

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=CA+55aFwo-48yKu+raRF3B9n1mqd1qV35eDq56Yi+erPygkuTvA@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=bhutchings@solarflare.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=linuxram@us.ibm.com \
    --cc=socketcan@hartkopp.net \
    --cc=yinghai@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.