Date: Thu, 19 Apr 2012 10:38:33 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Bernhard Schmidt <bschmidt@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? Message-ID: <CAJ-Vmo=_MTvHVRvCBSpvo9ToiLHe9_X=OZHiXqhASm16VFvBuA@mail.gmail.com> In-Reply-To: <CAAgh0_aYFGHNpuiHweYNd2qzfkydsfAHsPzEM2xWaOScoZTFcw@mail.gmail.com> References: <CAJ-Vmo=L8jhvBwoLpF1Hu1M870ZV%2Bp-G5Vn6HW-HCFV842KLBw@mail.gmail.com> <CAAgh0_agsfY66Se7ej8VhGhNeAcKUTJO8KMY8Frhq1qZvfem-Q@mail.gmail.com> <CAAgh0_aYFGHNpuiHweYNd2qzfkydsfAHsPzEM2xWaOScoZTFcw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Right, so we can treat ni_txrate as "don't interpret the basic flag on this." Are you happy with a project to migrate rate's from uint8_t to an opaque struct? That way we can: * add basic, mcs flags; * get ready for the 802.11ac rate configuration mess that's about to occur; * leverage the compiler to tell us when we're trying to do something like uint8_t <-> rate_t, rather than moving it to a uint16_t which the compiler will automagically promote/extend as necessary. It's probably quite ugly, but I think it's necessary to "grow". Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=_MTvHVRvCBSpvo9ToiLHe9_X=OZHiXqhASm16VFvBuA>