From owner-freebsd-arch@FreeBSD.ORG Sun Aug 7 10:38:19 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55027106567B; Sun, 7 Aug 2011 10:38:19 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id 77F668FC9F; Sun, 7 Aug 2011 10:37:54 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id A1449BCB2A; Sun, 7 Aug 2011 10:37:53 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id yl3IAzCrpp+K; Sun, 7 Aug 2011 10:37:51 +0000 (UTC) Received: from [192.168.4.21] (4304ds2-vlb.1.fullrate.dk [90.184.171.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id D928DBCB20; Sun, 7 Aug 2011 10:37:50 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Simon L. B. Nielsen" In-Reply-To: <4E25BB7C.4090106@FreeBSD.org> Date: Sun, 7 Aug 2011 12:37:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <005878F6-3CF5-482E-98E8-E5E4B8CA6C99@nitro.dk> References: <4E114EA9.4000605@FreeBSD.org> <20110718190839.GA81421@psconsult.nl> <4E25BB7C.4090106@FreeBSD.org> To: Jamie Gritton X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-jail@FreeBSD.org, Paul Schenkeveld , freebsd-arch@FreeBSD.org Subject: Re: New jail(8) with configuration files, not yet in head X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 10:38:20 -0000 On 19 Jul 2011, at 19:14, Jamie Gritton wrote: > On 07/18/11 13:08, Paul Schenkeveld wrote: >=20 >> Although I really like this new functionality, there is one issue = that >> I am concerned about. Should all this functionality be integrated = into >> the jail(8) command? >=20 > This project came from a desire to improve the jail startup procedure = in rc.d/jail, which remains stuck handling the old fixed-parameter = jails. Rather that continue to extend an already unwieldy number of = rc.conf shell variables, I opted to add a configuration file like other = subsystems use (e.g. apmd, devd). The new jail pseudo-parameters added = to the config file exist mostly to match the existing rc.d/jail = functionality - the mount.* and exec.* parameters are direct analogs to = rc.conf shell variables. Some other parameters match the command-line = options of the existing jail(8). [This is less a mail to Jamie and more me getting around to publicly = supporting they way it's done] A thing to note is also that when starting a jail you have to be really = careful to do all of the related operations in the right order and in a = safe manner. E.g. mounting file systems are only safe in some = circumstances (ref: symlink attacks) so that's one reason I think the = new approach is the right one. Also try reading the current rc.d/jail = code for checking for those symlinks etc... not pretty. There are also some other quirks which means a slightly more = comprehensive program is better. E.g. current rc.d jails have a bug = where they can actually fill /tmp if they produce a lot of console = output due to redirection to temp file (this is rarely a real problem so = I never gotten around to trying to fix it). Bloat is of course a concern, but I don't think that risk outweigh the = benefits of Jamie's new work. There is still room and need for a wrapper management framework (ezjail = or something close to it) which handles the actual creation, update etc. = which makes sense as a separate utility not part of jail(8). ezjail = already uses rc.d/jail heavily so I think it can nicely integrate with = the new jail(8). > I wouldn't want to do away with a config file, as that's a much = cleaner way to define multiple jails than depending on the rc system or = requiring a "roll your own" approach that is currently the only way to = use the newer features. Just reading /etc/rc.d/jail is IMO good proof of this... > It's clear now that this won't be happening in 9.0. So none of this = is in danger of getting pushed through in a hurry. I really hope that this can go into head shortly after the branch so it = can hopefully make it into 9.1. --=20 Simon L. B. Nielsen From owner-freebsd-arch@FreeBSD.ORG Sun Aug 7 19:05:26 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25FE41065670; Sun, 7 Aug 2011 19:05:26 +0000 (UTC) (envelope-from joris.dedieu@gmail.com) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id CC4988FC0A; Sun, 7 Aug 2011 19:05:25 +0000 (UTC) Received: by iye7 with SMTP id 7so7657795iye.17 for ; Sun, 07 Aug 2011 12:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+eH8/nP8YMduuzAdUMe185OCjTBX1rtFjKhu4Q1m54w=; b=IeGP6+qVqDXOkUhGEDlP6mqHoO+dLfbmZyEeIE/SImVF8hkt+h8BRp7xtFFFpxFzmT nJTr32t5MxM41Wa4he30EBpRBn0kDyWdXk66oKwr6kQaNR4D1BLKHXxbu/cMrY2fHoSF Vtad1xvFV3VSi6Jta7oqBP2qk/EhcSKG8fdBU= MIME-Version: 1.0 Received: by 10.231.91.69 with SMTP id l5mr3996155ibm.47.1312742529326; Sun, 07 Aug 2011 11:42:09 -0700 (PDT) Received: by 10.231.13.204 with HTTP; Sun, 7 Aug 2011 11:42:09 -0700 (PDT) In-Reply-To: <005878F6-3CF5-482E-98E8-E5E4B8CA6C99@nitro.dk> References: <4E114EA9.4000605@FreeBSD.org> <20110718190839.GA81421@psconsult.nl> <4E25BB7C.4090106@FreeBSD.org> <005878F6-3CF5-482E-98E8-E5E4B8CA6C99@nitro.dk> Date: Sun, 7 Aug 2011 20:42:09 +0200 Message-ID: From: joris dedieu To: "Simon L. B. Nielsen" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-jail@freebsd.org, Paul Schenkeveld , Jamie Gritton , freebsd-arch@freebsd.org Subject: Re: New jail(8) with configuration files, not yet in head X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 19:05:26 -0000 2011/8/7 Simon L. B. Nielsen : > > On 19 Jul 2011, at 19:14, Jamie Gritton wrote: > >> On 07/18/11 13:08, Paul Schenkeveld wrote: >> >>> Although I really like this new functionality, there is one issue that >>> I am concerned about. =A0Should all this functionality be integrated in= to >>> the jail(8) command? >> >> This project came from a desire to improve the jail startup procedure in= rc.d/jail, which remains stuck handling the old fixed-parameter jails. Rat= her that continue to extend an already unwieldy number of rc.conf shell var= iables, I opted to add a configuration file like other subsystems use (e.g.= apmd, devd). =A0The new jail pseudo-parameters added to the config file ex= ist mostly to match the existing rc.d/jail functionality - the mount.* and = exec.* parameters are direct analogs to rc.conf shell variables. =A0Some ot= her parameters match the command-line options of the existing jail(8). > > [This is less a mail to Jamie and more me getting around to publicly supp= orting they way it's done] > > A thing to note is also that when starting a jail you have to be really c= areful to do all of the related operations in the right order and in a safe= manner. E.g. mounting file systems are only safe in some circumstances (re= f: symlink attacks) so that's one reason I think the new approach is the ri= ght one. Also try reading the current rc.d/jail code for checking for those= symlinks etc... not pretty. > > There are also some other quirks which means a slightly more comprehensiv= e program is better. =A0E.g. current rc.d jails have a bug where they can a= ctually fill /tmp if they produce a lot of console output due to redirectio= n to temp file (this is rarely a real problem so I never gotten around to t= rying to fix it). > > Bloat is of course a concern, but I don't think that risk outweigh the be= nefits of Jamie's new work. > > There is still room and need for a wrapper management framework (ezjail o= r something close to it) which handles the actual creation, update etc. whi= ch makes sense as a separate utility not part of jail(8). ezjail already us= es rc.d/jail heavily so I think it can nicely integrate with the new jail(8= ). > >> I wouldn't want to do away with a config file, as that's a much cleaner = way to define multiple jails than depending on the rc system or requiring a= "roll your own" approach that is currently the only way to use the newer f= eatures. > > Just reading /etc/rc.d/jail is IMO good proof of this... > >> It's clear now that this won't be happening in 9.0. =A0So none of this i= s in danger of getting pushed through in a hurry. > > I really hope that this can go into head shortly after the branch so it c= an hopefully make it into 9.1. IMHO It's a need. Jails v2 effort began in 7.2 with multiple ip support. /etc/rc.d/jail is clearly unpatchable (see comments in conf/142972). It's now reasonable to think that a way to cleanly start jails v2 at boot time can be hoped form OS primitives. Joris > > -- > Simon L. B. Nielsen > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Aug 8 10:14:24 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E91A1065673 for ; Mon, 8 Aug 2011 10:14:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D128D8FC12 for ; Mon, 8 Aug 2011 10:14:23 +0000 (UTC) Received: by vxh11 with SMTP id 11so1680440vxh.13 for ; Mon, 08 Aug 2011 03:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZKBGNLmL6K8BAbyty2UDKL9qPt3Uttsorn/E7DVrC1A=; b=I0+aXzasqLY25KDXY36Ed8g78h33Vu7YUdmuPNeedjMYV+dmtQDud30mYGFYOlvdQC C0Miz8m7q+20myJJml8u8nQt9Sc6qlCLGDeKYZHCh/NrcErC2F/uPU8ky3LJkIOCyPza 92PLsgrAkw37EWmKL0Er8WmBLAxKRkUqIS244= MIME-Version: 1.0 Received: by 10.52.95.163 with SMTP id dl3mr4978233vdb.229.1312796978268; Mon, 08 Aug 2011 02:49:38 -0700 (PDT) Received: by 10.52.157.193 with HTTP; Mon, 8 Aug 2011 02:49:38 -0700 (PDT) Date: Mon, 8 Aug 2011 17:49:38 +0800 Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: [RFQ] net80211 regulatory changes: what I'd like to see before 9.0-RELEASE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 10:14:24 -0000 Hi all, I've been knee-deep in the net80211 regulatory code (among other things) and after doing some regulatory DFS related work, there's a couple of short-comings I'd like to try and fix before 9.0-RELEASE is fixed. Firstly, the current way that regulatory domains in net80211 are setup is very Atheros-specific. Specifically, the notion of "SKU" as the regulatory domain. net80211 knows about a small subset of SKU values which mostly map to what the Atheros driver/HAL code uses to figure out the regulatory domain. But it makes it impossible to extend the regulatory domain database (regdomain.xml) to encompass the different regulatory domains that exist for different countries. For example, if I wanted to add an Australia specific regulatory domain (which would include information different to the "ROW" (rest-of-world) regulatory domain it currently defaults to using), I'd have to teach net80211 about a new SKU (call it "APAC".) But since the Atheros HAL doesn't have an Australia specific SKU value, I'd have to choose a value which didn't conflict. Since the regdomain.xml database is indexed by the SKU value, I can't have more than one regulatory domain with the same SKU. Since net80211/atheros rejects SKUs it doesn't know about, I'd have to add each new (fake) SKU to both in order to get things working. What I'd like to do is modify the regdomain.xml database, net80211 and ifconfig to use the ISOCC (ISO country code) numeric value as the primary key. This means an ABI change, as the primary key won't be an SKU any longer, but keep the SKU as a field so people using atheros devices can see what's going on. Once that's done, I/others can then spend the next few months slowly adding updated entries to regdomain.xml that reflect what each of the current country regulatory requirements are. The second change would be brought in with the first change. I'd like to add another field to regdomain.xml which includes what the radar requirements are - specifically for now, whether it's FCC, Japan, ETSI. The atheros driver seems to support combinations of the above when using one of the world regulatory domains (FCC and ETSI together) so it likely should be some more flags. I can knock up some public code in the next few days to submit for review. Thanks, Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Aug 8 13:31:30 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E88E106566B; Mon, 8 Aug 2011 13:31:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 06EF68FC13; Mon, 8 Aug 2011 13:31:29 +0000 (UTC) Received: by vws18 with SMTP id 18so2667301vws.13 for ; Mon, 08 Aug 2011 06:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=csc12jsJsRVrzGDSwkAZmyPgTLQj5Tkma4Mwnl+betg=; b=mXzx55RV9FzAojYXniBfZWoeR2aKOLjBI/c960lg4C81QMdh0DhUQiYEkHkWzYp1LY rQXJymIA9zBOkUNwfiyO2u5eXhSG84K/avVeIoentyf38qXLVz9m4CSQ4lO+1hXCehoa 6LVIKyKXP+Ot2QU+5A/n/ynfusM6Gta12ypM4= MIME-Version: 1.0 Received: by 10.52.94.139 with SMTP id dc11mr3513467vdb.28.1312810289304; Mon, 08 Aug 2011 06:31:29 -0700 (PDT) Received: by 10.52.157.193 with HTTP; Mon, 8 Aug 2011 06:31:29 -0700 (PDT) In-Reply-To: <201108081525.21563.bschmidt@freebsd.org> References: <201108081525.21563.bschmidt@freebsd.org> Date: Mon, 8 Aug 2011 21:31:29 +0800 Message-ID: From: Adrian Chadd To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFQ] net80211 regulatory changes: what I'd like to see before 9.0-RELEASE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 13:31:30 -0000 On 8 August 2011 21:25, Bernhard Schmidt wrote: > We've discussed this on IRC already, though to mention it again what I > > really like to get rid of is all the SKU stuff from the regdomain.xml. This > is > > specific to ath(4) and ath(4) only. Yup, I agree. ath/ath_hal can export a default country code for the given SKU. The only reason I'd maintain the SKU is so tools that currently expose that value keep working (ie, to read the EEPROM value from the NIC.) But it won't be used anywhere else for configuration/ > Using the isocc as the index is correct and really the way to go, but it > > might not serve some corner cases that well. Imagine someone wants > > to set a regdomain and not a country (we DO support this currently), > > how do want to express that in regdomain.xml? Adding a dummy isocc > > for each regdomain (FCC, ETSI, ..)? Maybe we should use (isocc,regdomain) > > as the index, so it is possible to use issoc=0,regdomain={FCC,ETSI,..} > > for the mentioned case. You'd just create or use a NONE ISOCC, and set your regulatory domain to whatever. The ISO CC is just a key to find a default regulatory domain. Some countries may share the same regulatory domain because they (for example) implement 100% of the USA FCC rules. But many won't, so I think we'll likely see something more like CRDA where each country gets enumerated. There'll also (for now) be custom SKUs/regulatory domains - specifically to drive the net80211ath/ath_hal GSM configuration (900mhz.) net80211 handles 900mhz frequencies. The SKU choice "tells" the ath/hal code to use the relevant channel mapping. That's the main reason I don't want to yet get rid of SKUs. I can worry about that part later. Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Aug 8 13:33:52 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B22E106566C; Mon, 8 Aug 2011 13:33:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F37208FC08; Mon, 8 Aug 2011 13:33:51 +0000 (UTC) Received: by vws18 with SMTP id 18so2669974vws.13 for ; Mon, 08 Aug 2011 06:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U2bjp+SweJu98fJkfFXHlogIAw794d1M8WMqa8n2j0Q=; b=HtIR+05V+Ea7+YPabtQTbiqpKdXb07FLu2b/NWFKSWeJ77DN2waSUWRFUxnRdh714B ta+Sp48QUaUabNg8o5Ldj0Z6M2LIQZaGjMviWvCF7YYKIzGChdrNDniYL7CcTawC560x +0Ai/ru04VgW6Jxe9e62UMzWE+fO6ypLeGOHY= MIME-Version: 1.0 Received: by 10.52.27.36 with SMTP id q4mr5690701vdg.296.1312810431344; Mon, 08 Aug 2011 06:33:51 -0700 (PDT) Received: by 10.52.157.193 with HTTP; Mon, 8 Aug 2011 06:33:51 -0700 (PDT) In-Reply-To: References: <201108081525.21563.bschmidt@freebsd.org> Date: Mon, 8 Aug 2011 21:33:51 +0800 Message-ID: From: Adrian Chadd To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFQ] net80211 regulatory changes: what I'd like to see before 9.0-RELEASE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 13:33:52 -0000 But to be clear - the SKU will only be used for that. Regulatory decisions will be based on the ISOCC and regdomain entry chosen. How about instead, I: * maintain regdomain.xml entries by name (eg FCC, ETSI, etc); * index regulatory domain by a regdomain "key", which is just an integer value which only has meaning in regdomain.xml - ie, replace how sku values are used in regdomain.xml (as the key) with "regdomain value"; * isocc entries in regdomain.xml have a "default" regulatory domain entry, as they do now. That way you can have multiple regdomain entries and you can choose whichever you want? Adrian On 8 August 2011 21:31, Adrian Chadd wrote: > On 8 August 2011 21:25, Bernhard Schmidt wrote: > >> We've discussed this on IRC already, though to mention it again what I >> >> really like to get rid of is all the SKU stuff from the regdomain.xml. This >> is >> >> specific to ath(4) and ath(4) only. > > Yup, I agree. ath/ath_hal can export a default country code for the given SKU. > The only reason I'd maintain the SKU is so tools that currently expose > that value keep working (ie, to read the EEPROM value from the NIC.) > > But it won't be used anywhere else for configuration/ > >> Using the isocc as the index is correct and really the way to go, but it >> >> might not serve some corner cases that well. Imagine someone wants >> >> to set a regdomain and not a country (we DO support this currently), >> >> how do want to express that in regdomain.xml? Adding a dummy isocc >> >> for each regdomain (FCC, ETSI, ..)? Maybe we should use (isocc,regdomain) >> >> as the index, so it is possible to use issoc=0,regdomain={FCC,ETSI,..} >> >> for the mentioned case. > > You'd just create or use a NONE ISOCC, and set your regulatory domain > to whatever. > > The ISO CC is just a key to find a default regulatory domain. Some > countries may share the same regulatory domain because they (for > example) implement 100% of the USA FCC rules. But many won't, so I > think we'll likely see something more like CRDA where each country > gets enumerated. > > There'll also (for now) be custom SKUs/regulatory domains - > specifically to drive the net80211ath/ath_hal GSM configuration > (900mhz.) net80211 handles 900mhz frequencies. The SKU choice "tells" > the ath/hal code to use the relevant channel mapping. That's the main > reason I don't want to yet get rid of SKUs. I can worry about that > part later. > > > > Adrian > From owner-freebsd-arch@FreeBSD.ORG Mon Aug 8 13:56:58 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EC231065689; Mon, 8 Aug 2011 13:56:58 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id B91BC8FC25; Mon, 8 Aug 2011 13:56:57 +0000 (UTC) Received: by eye4 with SMTP id 4so2859368eye.31 for ; Mon, 08 Aug 2011 06:56:56 -0700 (PDT) Received: by 10.204.142.131 with SMTP id q3mr1633363bku.51.1312809955670; Mon, 08 Aug 2011 06:25:55 -0700 (PDT) Received: from jessie.localnet (p5B2EDD35.dip0.t-ipconnect.de [91.46.221.53]) by mx.google.com with ESMTPS id n11sm1646245bkd.47.2011.08.08.06.25.54 (version=SSLv3 cipher=OTHER); Mon, 08 Aug 2011 06:25:54 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Mon, 8 Aug 2011 15:25:21 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.6.2; i686; ; ) References: In-Reply-To: X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201108081525.21563.bschmidt@freebsd.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFQ] net80211 regulatory changes: what I'd like to see before 9.0-RELEASE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 13:56:58 -0000 On Monday, August 08, 2011 11:49:38 Adrian Chadd wrote: > Hi all, > > I've been knee-deep in the net80211 regulatory code (among other > things) and after doing some regulatory DFS related work, there's a > couple of short-comings I'd like to try and fix before 9.0-RELEASE is > fixed. > > Firstly, the current way that regulatory domains in net80211 are setup > is very Atheros-specific. Specifically, the notion of "SKU" as the > regulatory domain. net80211 knows about a small subset of SKU values > which mostly map to what the Atheros driver/HAL code uses to figure > out the regulatory domain. But it makes it impossible to extend the > regulatory domain database (regdomain.xml) to encompass the different > regulatory domains that exist for different countries. For example, if > I wanted to add an Australia specific regulatory domain (which would > include information different to the "ROW" (rest-of-world) regulatory > domain it currently defaults to using), I'd have to teach net80211 > about a new SKU (call it "APAC".) But since the Atheros HAL doesn't > have an Australia specific SKU value, I'd have to choose a value which > didn't conflict. > > Since the regdomain.xml database is indexed by the SKU value, I can't > have more than one regulatory domain with the same SKU. Since > net80211/atheros rejects SKUs it doesn't know about, I'd have to add > each new (fake) SKU to both in order to get things working. > > What I'd like to do is modify the regdomain.xml database, net80211 and > ifconfig to use the ISOCC (ISO country code) numeric value as the > primary key. This means an ABI change, as the primary key won't be an > SKU any longer, but keep the SKU as a field so people using atheros > devices can see what's going on. > > Once that's done, I/others can then spend the next few months slowly > adding updated entries to regdomain.xml that reflect what each of the > current country regulatory requirements are. > > The second change would be brought in with the first change. I'd like > to add another field to regdomain.xml which includes what the radar > requirements are - specifically for now, whether it's FCC, Japan, > ETSI. The atheros driver seems to support combinations of the above > when using one of the world regulatory domains (FCC and ETSI together) > so it likely should be some more flags. > > I can knock up some public code in the next few days to submit for review. We've discussed this on IRC already, though to mention it again what I really like to get rid of is all the SKU stuff from the regdomain.xml. This is specific to ath(4) and ath(4) only. Using the isocc as the index is correct and really the way to go, but it might not serve some corner cases that well. Imagine someone wants to set a regdomain and not a country (we DO support this currently), how do want to express that in regdomain.xml? Adding a dummy isocc for each regdomain (FCC, ETSI, ..)? Maybe we should use (isocc,regdomain) as the index, so it is possible to use issoc=0,regdomain={FCC,ETSI,..} for the mentioned case. -- Bernhard