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.
prev parent 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).