From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-qa0-f47.google.com ([209.85.216.47]:65262 "EHLO mail-qa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753976AbaFIKWW (ORCPT ); Mon, 9 Jun 2014 06:22:22 -0400 Received: by mail-qa0-f47.google.com with SMTP id s7so7549193qap.20 for ; Mon, 09 Jun 2014 03:22:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <53956986.8070603@openwrt.org> References: <1399624824-9204-1-git-send-email-janusz.dziedzic@tieto.com> <20140520142453.GB13981@tuxdriver.com> <20140520180832.GD13981@tuxdriver.com> <1400610273.4474.6.camel@jlt4.sipsolutions.net> <1400688233.4136.8.camel@jlt4.sipsolutions.net> <53956986.8070603@openwrt.org> Date: Mon, 9 Jun 2014 12:22:21 +0200 Message-ID: (sfid-20140609_122232_111047_1C3D9064) Subject: Re: [PATCH] wireless-regdb: add DFS CAC time parameter From: Janusz Dziedzic To: Felix Fietkau Cc: Johannes Berg , "Luis R. Rodriguez" , "John W. Linville" , "wireless-regdb@lists.infradead.org" , linux-wireless Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 9 June 2014 10:00, Felix Fietkau wrote: > On 2014-05-21 18:03, Johannes Berg wrote: >> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote: >> >>> > I think we should, but if we can't then at least can we cut to an >>> > extensible format? >> >> I don't see any way to extend the format right now. >> >> There's a wrinkle with making it more extensible too though - if we do >> that then we must be extremely careful that future older crda versions >> (i.e. the next version that we're about to write) will not parse a newer >> extended file more permissively, so our extensions are limited anyway. >> >> Looks like the format update really is needed, which probably means we >> should change the scripts to generate two databases and change the >> filename, or so? > How about making the format properly extensible by reusing what we're > already doing to keep the kernel ABI stable? For example, we could store > the database in a netlink-like attribute format, with some changes to > make it fixed endian. > I'm already doing just that for a few things in OpenWrt, so I have > working C code for writing and parsing such a format. > > Another nice feature would be to indicate in the attributes if crda is > required to understand them, or if it can just continue with a warning. > > If done right, I think we can probably make this the last time we change > the format version. > What kind of benefit we have having binary format between crda <-> wireless-regd (nl-based or current regulatory.bin)? This is additional code/work to do - why we need that? BR Janusz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-qc0-x230.google.com ([2607:f8b0:400d:c01::230]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wtwiy-0008C7-Oa for wireless-regdb@lists.infradead.org; Mon, 09 Jun 2014 10:22:45 +0000 Received: by mail-qc0-f176.google.com with SMTP id r5so422851qcx.7 for ; Mon, 09 Jun 2014 03:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LSWHFqpQBJuFsn4v6lAPC9+kSEkRpv95bDJiKK4S2Qg=; b=Brq49aiLkTM2UHS1d9Tqjc/+oatQ1gfI3a4Rb9cm28vXiBULd40R2aPXGa5HgozC1Z Tcfkm5tA/YIRm5pqhHRa+G4jmC2I+bBDPd4wm64NArNHn6zFR4YMMcMkt8kqyT0TS0VI 4u1bbRwlM3d/qMDmpQT3P9eKcvjl4Ny5EwPkM= MIME-Version: 1.0 In-Reply-To: <53956986.8070603@openwrt.org> References: <1399624824-9204-1-git-send-email-janusz.dziedzic@tieto.com> <20140520142453.GB13981@tuxdriver.com> <20140520180832.GD13981@tuxdriver.com> <1400610273.4474.6.camel@jlt4.sipsolutions.net> <1400688233.4136.8.camel@jlt4.sipsolutions.net> <53956986.8070603@openwrt.org> Date: Mon, 9 Jun 2014 12:22:21 +0200 Message-ID: From: Janusz Dziedzic Subject: Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: "wireless-regdb" Errors-To: wireless-regdb-bounces+johannes=sipsolutions.net@lists.infradead.org Content-Transfer-Encoding: 8bit To: Felix Fietkau Cc: linux-wireless , Johannes Berg , "wireless-regdb@lists.infradead.org" , "John W. Linville" , "Luis R. Rodriguez" List-ID: On 9 June 2014 10:00, Felix Fietkau wrote: > On 2014-05-21 18:03, Johannes Berg wrote: >> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote: >> >>> > I think we should, but if we can't then at least can we cut to an >>> > extensible format? >> >> I don't see any way to extend the format right now. >> >> There's a wrinkle with making it more extensible too though - if we do >> that then we must be extremely careful that future older crda versions >> (i.e. the next version that we're about to write) will not parse a newer >> extended file more permissively, so our extensions are limited anyway. >> >> Looks like the format update really is needed, which probably means we >> should change the scripts to generate two databases and change the >> filename, or so? > How about making the format properly extensible by reusing what we're > already doing to keep the kernel ABI stable? For example, we could store > the database in a netlink-like attribute format, with some changes to > make it fixed endian. > I'm already doing just that for a few things in OpenWrt, so I have > working C code for writing and parsing such a format. > > Another nice feature would be to indicate in the attributes if crda is > required to understand them, or if it can just continue with a warning. > > If done right, I think we can probably make this the last time we change > the format version. > What kind of benefit we have having binary format between crda <-> wireless-regd (nl-based or current regulatory.bin)? This is additional code/work to do - why we need that? BR Janusz _______________________________________________ wireless-regdb mailing list wireless-regdb@lists.infradead.org http://lists.infradead.org/mailman/listinfo/wireless-regdb