linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Büsch" <mb@bu3sch.de>
To: Arend van Spriel <arend@broadcom.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
	"Brett Rudley" <brudley@broadcom.com>,
	"Henry Ptasinski" <henryp@broadcom.com>,
	"John Linville" <linville@tuxdriver.com>,
	"George Kashperko" <george@znau.edu.ua>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: new utility kernel module for detecting cores in newer chipsets
Date: Mon, 21 Mar 2011 17:28:06 +0100	[thread overview]
Message-ID: <1300724886.23263.29.camel@maggie> (raw)
In-Reply-To: <1300724675.23263.26.camel@maggie>

On Mon, 2011-03-21 at 17:24 +0100, Michael Büsch wrote: 
> On Mon, 2011-03-21 at 16:05 +0100, Arend van Spriel wrote: 
> > To summarize this, my main issue (and Michael's, I think) is with the  
> > dependency being imposed between ai and ssb.
> 
> That's part of my main issue, right.
> 
> > Having two completely independent modules really makes more sense.
> 
> I do think that any attempt to merge legacy-ssb with ai subsystems
> or even share significant amounts of code between these subsystems
> will result in a maintenance nightmare.
> 
> There are times where a fork or a rewrite is the best thing to do.
> And I think that is the case here.
> 
> SSB hardware is dead. Let the software die, too.
> You just need to realize that having ai code completely separate from
> ssb code makes life easier for you guys.
> Win: You don't need to take care about backwards compatibility.
> Win: You don't break our legacy devices.
> 
> Just look at the patches you guys already sent. Look at that TMSLOW
> abstraction layer, for instance. That's just a pain in the arms.
> Look at that:
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/66590
> You're carrying old legacy cruft into the shiny new subsystem
> (PCMCIA support, for instance) just to avoid duplicating a trivial
> 100 line function.
> 
> Please keep in mind that any attempt to merge SSB with AI code means
> that _you_ guys will have to maintain backwards compatibility
> with devices designed 10 years ago.
> 
> I really don't understand why you are so resistant against a fork
> or a rewrite, because it makes _your_ life easier (and mine, too).
> 
> PS: I do _not_ know whether the brcmaix code is reasonable or even
> useful
> as base to build up the new broadcom SOC bus subsystem, so I'm not
> going to pass and judgement on that code.
> 

I just realized that Arend was in the To: field.
The text was mainly addressed to Rafal and George. Probably Greg as
well.

-- 
Greetings Michael.


      reply	other threads:[~2011-03-21 16:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <op.vslagcb13ri7v4@arend-laptop>
2011-03-19 12:13 ` new utility kernel module for detecting cores in newer chipsets Arend van Spriel
2011-03-20  9:55   ` Rafał Miłecki
2011-03-20 13:07     ` George Kashperko
2011-03-20 17:04       ` Arend van Spriel
     [not found] ` <1300538338.11949.12.camel@maggie>
     [not found]   ` <20110319214234.GA5152@kroah.com>
     [not found]     ` <1300573336.11949.25.camel@maggie>
     [not found]       ` <20110319234524.GA7493@kroah.com>
     [not found]         ` <op.vsmyhmei3ri7v4@arend-laptop>
     [not found]           ` <20110320145421.GA13962@kroah.com>
     [not found]             ` <op.vsnd1a1i3ri7v4@arend-laptop>
     [not found]               ` <20110320162200.GA17030@kroah.com>
     [not found]                 ` <op.vsng7q1j3ri7v4@arend-laptop>
     [not found]                   ` <20110320185216.GD19375@kroah.com>
2011-03-21 10:12                     ` Rafał Miłecki
2011-03-21 14:05                       ` Greg KH
2011-03-21 14:27                         ` Rafał Miłecki
2011-03-21 14:46                           ` Greg KH
2011-03-21 14:52                             ` Rafał Miłecki
2011-03-21 15:16                               ` Greg KH
2011-03-21 15:33                                 ` Rafał Miłecki
2011-03-21 15:05                           ` Arend van Spriel
2011-03-21 15:14                             ` John W. Linville
2011-03-21 15:30                             ` Rafał Miłecki
2011-03-21 16:25                               ` George Kashperko
2011-03-21 16:24                             ` Michael Büsch
2011-03-21 16:28                               ` Michael Büsch [this message]

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=1300724886.23263.29.camel@maggie \
    --to=mb@bu3sch.de \
    --cc=arend@broadcom.com \
    --cc=brudley@broadcom.com \
    --cc=george@znau.edu.ua \
    --cc=henryp@broadcom.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=zajec5@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).