From owner-freebsd-wireless@FreeBSD.ORG Thu Apr 19 17:38:36 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 357DA1065674; Thu, 19 Apr 2012 17:38:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3598FC18; Thu, 19 Apr 2012 17:38:35 +0000 (UTC) Received: by lagv3 with SMTP id v3so8498033lag.13 for ; Thu, 19 Apr 2012 10:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Xbkxv8FVDy23I6vFJxpFCxSJqEu2SJz/Vd8a2G014jY=; b=ohQWYFRNkeOzh2KZKqddyMRpXBo3tsOLZBOx9hGolEG7fFSrHWv4Eh3XzEzYMoqNcK VgYzulAT/+CaMMmdgKl6DmN1C2lbvV+We0QRfRmmsoKDRVzk931WxvHFCRtzYuZHHTKw vPAWQKrvJd0muh+71Ia54Nnscdirm2XnqNQcPBhdUwQywchbDIznaNjipROUusy/TxYQ gLjWghvbUwMw0Jy4+abDCg7Wx42XASTLrNjc1rcmKTLVcpzMBvwPhgA9ebe9g3gGMfaC +7pdh4LRbpfwanMxykuRy6X/FVlfyC25x42SYH9E4ZxFjjEAaPn+nu4aINaVqw70rHog pg7g== MIME-Version: 1.0 Received: by 10.152.145.135 with SMTP id su7mr504835lab.5.1334857113567; Thu, 19 Apr 2012 10:38:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.112.106.71 with HTTP; Thu, 19 Apr 2012 10:38:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Apr 2012 10:38:33 -0700 X-Google-Sender-Auth: KyUbLnOvniYAAfhQBJYt3fKZ8Yk Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 17:38:36 -0000 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