All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: David Kimdon <david.kimdon@devicescape.com>
Cc: netdev@vger.kernel.org, madwifi-devel@lists.sourceforge.net,
	Nick Kossifidis <mickflemm@gmail.com>,
	Michael Buesch <mb@bu3sch.de>
Subject: Re: ar5k and Atheros AR5005G
Date: Wed, 29 Nov 2006 12:13:12 -0800	[thread overview]
Message-ID: <20061129121312.4cfc254f@freekitty> (raw)
In-Reply-To: <20061129160328.GA22602@devicescape.com>

On Wed, 29 Nov 2006 08:03:28 -0800
David Kimdon <david.kimdon@devicescape.com> wrote:

> On Wed, Nov 29, 2006 at 04:38:56PM +0100, Michael Buesch wrote:
> > On Wednesday 29 November 2006 16:24, David Kimdon wrote:
> > > On Wed, Nov 29, 2006 at 04:12:33PM +0100, Michael Buesch wrote:
> > > > On Wednesday 29 November 2006 15:34, Nick Kossifidis wrote:
> > > Why do you say that?
> > > 
> > > There is absolutely no reason why dadwifi can't be merged into the
> > > mainline once the hal issue is resolved. 
> > 
> > Last time we talked about that stuff, it was decided that
> > we don't want a HAL... See archives.
> 
> To be clear, that is all part of the hal issue that needs to be
> resolved.  Removing the hal abstraction is not difficult for an
> interested party once source for the hal is available.  The next step
> in such an effort would be to add an open hal to dadwifi, IMO.
> 

Isn't it obvious. Planning from goal through intermediate steps gives:

0 - today (raw materials)
	* softmac stack: d80211
	* open hal: ar5k
	* glue layer: dadwifi

1- put pieces together
	* d80211 + dadwifi + ar5k

2 - release working code to d80211 tree

3 - hard link dad2ifi to ar5k (one module)

4 - collapse indirect calls and refactor

5 - lather rinse repeat in public d80211 tree

...

8 - resulting in atheros driver kernel module

9 - code ready in d80211


10 - mainline integration of working driver for Atheros
     using common softmac stack

> 
> P.S. Actually, it isn't clear to me that removing the hal entirely is
> a good idea.  Abstractions exist for practical reasons.  The hal
> allows dadwifi to support a variety of Atheros chips without needing
> to worry about the specific details of each chip.

Abstractions that deal with hardware are good. See phylib.
Abstractions that try to deal with operating system independence are 
gross.



-- 
Stephen Hemminger <shemminger@osdl.org>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

  reply	other threads:[~2006-11-29 20:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-28 20:39 ar5k and Atheros AR5005G Daniel Drake
2006-11-28 20:45 ` Michael Buesch
2006-11-29 13:55   ` [Madwifi-devel] " Nick Kossifidis
2006-11-29 14:05     ` Michael Buesch
2006-11-29 14:34       ` Nick Kossifidis
2006-11-29 15:12         ` Michael Buesch
2006-11-29 15:21           ` Dan Williams
2006-11-29 15:30             ` David Kimdon
2006-11-29 15:24           ` David Kimdon
2006-11-29 15:38             ` Michael Buesch
2006-11-29 15:58               ` Michael Renzmann
2006-11-29 16:03                 ` Michael Buesch
2006-11-30  5:33                   ` Michael Renzmann
2006-11-29 16:03               ` [Madwifi-devel] " David Kimdon
2006-11-29 20:13                 ` Stephen Hemminger [this message]
2006-12-01 18:35                   ` Luis R. Rodriguez
2006-12-01 18:37                     ` Luis R. Rodriguez
2006-12-05 14:39                     ` Michael Renzmann
2006-12-05 15:15                       ` Luis R. Rodriguez
2006-12-05 17:18                         ` Stephen Hemminger
2006-12-05 18:57                           ` Luis R. Rodriguez
2006-11-29 15:47             ` Michael Buesch
2006-11-29 15:56     ` Daniel Drake

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=20061129121312.4cfc254f@freekitty \
    --to=shemminger@osdl.org \
    --cc=david.kimdon@devicescape.com \
    --cc=madwifi-devel@lists.sourceforge.net \
    --cc=mb@bu3sch.de \
    --cc=mickflemm@gmail.com \
    --cc=netdev@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.