From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladimir Kondratiev Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Wed, 29 Sep 2004 09:10:08 +0200 Sender: netdev-bounce@oss.sgi.com Message-ID: <200409290910.13201.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409282229.53349.vkondra@mail.ru> <20040929004808.GN30131@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1664376.XdjzlfJnxg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Cc: "Luis R. Rodriguez" , greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Return-path: To: "Luis R. Rodriguez" In-Reply-To: <20040929004808.GN30131@ruslug.rutgers.edu> Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org --nextPart1664376.XdjzlfJnxg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote: LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote: LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote: LR> > LR> RFC: what are the chances we can implement our own generic "softmac" that may LR> > LR> be usable by the different chipsets out there? LR> > LR> > Coming days, I will submit "framework" consisting of stack based on Dave's LR> > code and debug driver which will be able to imitate Rx. I have working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces stack-driver and LR> > stack-upper layers. It would be great if someone wi= ll do MAC algorithms. I'll LR> > appreciate this for sure. LR> LR> But would it be possible? Would it work, if we write our own softmac LR> interface? Or are softmac interaces/libraries strictly dependent on a LR> chipset being used? LR> LR> Luis LR> In idea yes, 802.11 stack should serve any low level driver provided it can= =20 Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The=20 difference is, 802.11 stack is not written yet, we need to make sure we do = it=20 in smart way and with reasonable assumptions about what low level driver ca= n=20 do. Thus far, I assume, low level driver (and NIC, of course) can: =2DTx/Rx arbitrary data and management packets. Control frames generated by= NIC. =2DNIC can perform scanning and report beacons or probe resp. to the stack. =2DNIC can report some basic PHY data per packet: rate, RSSI, maybe somethi= ng=20 else. =2DNIC accept some basic PHY data per packet on Tx: rate, retry count,=20 protection, maybe Tx power and some others =2DNIC can do crypto transformations on both Tx and Rx. For this, crypto ke= y=20 need be provided per packet for Tx and some ,mechanism to provide key for=20 each peer need to be established for Rx. =2DNIC may choose to not do fragmentation/reassembly, stack will handle it. =2DNIC may have many Tx queues for QoS, it will be able to start/stop each = one. To not raise unsupported expectations: 802.11 stack is only skeleton for no= w.=20 I will do interface parts first. For actual algorithms to handle management= s=20 flows, help required. But, I believe it is wise to write these algorithms=20 once for this stack rather to implement whole stack with each driver. Vladimir. --nextPart1664376.XdjzlfJnxg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBWl/Vqxdj7mhC6o0RAsdcAJ0Xh/rMiTIkCJTmT0j5N6zDzorbBwCeIMdp MHSGANCTe8mnVhSrzgAJaFY= =cRqX -----END PGP SIGNATURE----- --nextPart1664376.XdjzlfJnxg--