From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:30:18 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 921773A6; Mon, 11 Nov 2013 20:30:18 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4DB2497; Mon, 11 Nov 2013 20:30:17 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 9D1A958392; Mon, 11 Nov 2013 14:30:11 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id y4ulwpv8TmrF; Mon, 11 Nov 2013 14:30:11 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 7A80C58391; Mon, 11 Nov 2013 14:30:11 -0600 (CST) Message-ID: <52813E53.20403@freebsd.org> Date: Mon, 11 Nov 2013 14:30:11 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske , Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , Peter Grehan , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:30:18 -0000 On 11/11/13 14:18, Teske, Devin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: > > > Hello all, > > I have been experimenting with various BSD and GNU/Linux boot media > under bhyve and noticed that we may want to accommodate the "LiveCD" > mode of the installer, which in turn requires the correct console. > > Currently, one is prompted for VT100 for installation but this does not > appear to work/stick for LiveCD mode. > > Can anyone verify this? > > > While I developed this patch... > http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10&view=markup > > Reasons exist to search for a better solution, see here: > http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html > (and messages that follow it) > > Is modifying init(8) still the way to go? What modification do we want to make? > I'll do the work if we can come to consensus. > > Or should we touch up the patch in some way to address the original concerns? > I think modifying init is the way to go -- it keeps the install system from interfering with the installed one, as well as fixing this kind of issue with moved hard drives or PXE booting or what have you. If we can provide a guarantee that any system that displays text has a working console (unless explicitly configured not to), useability is improved. I would propose one of the following (and volunteer to write the code): Option A ------------ 1. init checks if there is an entry in /etc/ttys for the terminal[s] corresponding to the value[s] in kern.console 2. If an entry for each console terminal exists in /etc/ttys, enable it 3. If not, invent one with a terminal type of "ansi" The one issue here is that someone may want to force a particular entry to off and still have it be the kernel console. This is tricky. We could invent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifconsole"?). Which brings us to: Option B ----------- Very similar to Option A, except only provide an automatic console using (2) and (3) if the "console" terminal is marked "on". This would increase the magic attached to "console" in /etc/ttys, but fix the problem with (A). It's possible another approach would work as well. Does anyone have thoughts on this? -Nathan From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:43:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A3453286; Mon, 11 Nov 2013 20:43:24 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6009F25C2; Mon, 11 Nov 2013 20:43:24 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id C59CB11E42; Tue, 12 Nov 2013 06:43:22 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BPY31834 (AUTH peterg@ptree32.com.au); Tue, 12 Nov 2013 06:43:20 +1000 Message-ID: <52814166.4040105@freebsd.org> Date: Mon, 11 Nov 2013 12:43:18 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nathan Whitehorn , Devin Teske , Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: <52813E53.20403@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:43:24 -0000 Hi Nathan, > I think modifying init is the way to go -- it keeps the install system > from interfering with the installed one, as well as fixing this kind of > issue with moved hard drives or PXE booting or what have you. I now agree with this :) Modifying /etc/ttys at install time doesn't work for a lot of cases, LiveCD being the most obvious. > I would propose one of the following (and volunteer to write the code): > > Option A > ------------ > > 1. init checks if there is an entry in /etc/ttys for the terminal[s] > corresponding to the value[s] in kern.console > 2. If an entry for each console terminal exists in /etc/ttys, enable it > 3. If not, invent one with a terminal type of "ansi" > > The one issue here is that someone may want to force a particular entry > to off and still have it be the kernel console. This is tricky. We could > invent a new "status" field that is not "on" or "off" ("auto", maybe, or > "ifconsole"?). Which brings us to: I'd guess that this mode is really a once-off thing - for a live CD, init could ask the user if they want a getty spawned on this tty similar to asking for a shell in single-user mode. Presumably post-install the user would have edited the ttys file and init would then be able to locate the entry and not have to prompt. later, Peter. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:44:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB4B9450; Mon, 11 Nov 2013 20:44:41 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EE5125E2; Mon, 11 Nov 2013 20:44:41 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKickN032145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:44:40 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:44:16 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:44:15 +0000 Message-ID: References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: <52813E53.20403@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B18163F37F1CF46B1D1634B73334A3F@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: "Teske, Devin" , Current Current , "freebsd-arch@freebsd.org" , Devin Teske , Peter Grehan , Michael Dexter X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:44:41 -0000 On Nov 11, 2013, at 12:30 PM, Nathan Whitehorn wrote: > On 11/11/13 14:18, Teske, Devin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >>=20 >> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>=20 >>=20 >> Hello all, >>=20 >> I have been experimenting with various BSD and GNU/Linux boot media >> under bhyve and noticed that we may want to accommodate the "LiveCD" >> mode of the installer, which in turn requires the correct console. >>=20 >> Currently, one is prompted for VT100 for installation but this does not >> appear to work/stick for LiveCD mode. >>=20 >> Can anyone verify this? >>=20 >>=20 >> While I developed this patch... >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.sf.net/= viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascript= s%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=3D%2FbkpAUdJWZuiT= ILCq%2FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0= A&m=3DCRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=3D3e5345ea6b1= 3f84e719068bb993b66978f1971b648b430edfde9165677c279de >>=20 >> Reasons exist to search for a better solution, see here: >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/pi= permail/freebsd-current/2013-November/046148.html&k=3D%2FbkpAUdJWZuiTILCq%2= FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3D= CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=3D9ebff0354adb26340= 06e52cb4c0048287b7518bd7f4defe420ce5f34675ce5cd >> (and messages that follow it) >>=20 >> Is modifying init(8) still the way to go? What modification do we want t= o make? >> I'll do the work if we can come to consensus. >>=20 >> Or should we touch up the patch in some way to address the original conc= erns? >>=20 >=20 > I think modifying init is the way to go -- it keeps the install system fr= om interfering with the installed one, as well as fixing this kind of issue= with moved hard drives or PXE booting or what have you. If we can provide = a guarantee that any system that displays text has a working console (unles= s explicitly configured not to), useability is improved. >=20 > I would propose one of the following (and volunteer to write the code): >=20 > Option A > ------------ >=20 > 1. init checks if there is an entry in /etc/ttys for the terminal[s] corr= esponding to the value[s] in kern.console Is kern.console set by bhyve while NULL or unset when booting from a physical PC (bare metal)? > 2. If an entry for each console terminal exists in /etc/ttys, enable it > 3. If not, invent one with a terminal type of "ansi" >=20 > The one issue here is that someone may want to force a particular entry t= o off and still have it be the kernel console. This is tricky. We could inv= ent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifco= nsole"?). Which brings us to: >=20 Trying to think of an edge-case where they would want to force it to off. If the kern.console setting is only expected to be set via ... help me out = here... + bhyve ? + pxe ? + what else ? Then maybe the secret sauce shouldn't be in /etc/ttys, but in the value that is passed in via kern.console (that is, ... of the above ruminated technolo= gies which allow you to customize the value?) > Option B > ----------- >=20 > Very similar to Option A, except only provide an automatic console using = (2) and (3) if the "console" terminal is marked "on". This would increase t= he magic attached to "console" in /etc/ttys, but fix the problem with (A). >=20 > It's possible another approach would work as well. Does anyone have thoug= hts on this? If I'm not wrong, there's a third Option C that skirts the issue by bolster= ing the ability to change things for different needs. That prior change that I had made to bsdinstall/scripts/config (iirc) was a= big agressive because it tried to automatically figure things out. If we simply made it a choice (a scriptable one), then that would solve the= problem for the installation. But for the LiveCD issue (Michael wants to bring up the installer's LiveCD = via serial), then perhaps we could solve it by using unionfs in the installer to make th= e install environment writable (and again, change on-the-fly for different needs). Just a thought. Tell me if it's not an option ;D I won't mind. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:47:21 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 280DB787; Mon, 11 Nov 2013 20:47:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAC02261B; Mon, 11 Nov 2013 20:47:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F3DD5B9B3; Mon, 11 Nov 2013 15:47:19 -0500 (EST) From: John Baldwin To: clutton Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Mon, 11 Nov 2013 15:44:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1382572583.1862.39.camel@eva02.mbsd> <201311061159.14824.jhb@freebsd.org> <1383862923.70321.87.camel@eva02.mbsd> In-Reply-To: <1383862923.70321.87.camel@eva02.mbsd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201311111544.15187.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 11 Nov 2013 15:47:20 -0500 (EST) Cc: Bernhard Schmidt , Adrian Chadd , freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:47:21 -0000 On Thursday, November 07, 2013 5:22:03 pm clutton wrote: > On Wed, 2013-11-06 at 11:59 -0500, John Baldwin wrote: > > On Tuesday, November 05, 2013 5:17:30 pm John Baldwin wrote: > > > On Tuesday, November 05, 2013 2:33:50 pm Bernhard Schmidt wrote: > > > > On Tue, Nov 5, 2013 at 5:54 PM, John Baldwin wrot= e: > > > > > On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote: > > > > >> On 2 November 2013 12:13, clutton wrote: > > > > >> > > > > >> [snip] > > > > >> > > > > >> > What was happened? netif tries to setup wlan0 (clone, wpa, dhc= p,=20 etc), > > > > >> > when wlan0 interface occurs, devd runs another copy of netif. > > > > >> > > > > >> Well, it sounds like we need to pick an architecture _and_ fix t= he > > > > >> behaviour here. > > > > >> > > > > >> Which is: > > > > >> > > > > >> > > > > >> * I think wpa-supplicant should always run if it's required in=20 /etc/rc.conf; > > > > >> * netif should check if devd is configured and if so, just leave= =20 the > > > > >> configuration up to devd > > > > >> * if it isn't running, then devd should be responsible for > > > > >> dhclient/add-to-wpa-config > > > > >> > > > > >> What we first have to establish is whether add_interface and > > > > >> remove_interface (or whatever they're called) are correctly=20 working, > > > > >> for ethernet and wifi driver types. Then, we need to ensure they= =20 can > > > > >> coexist (ie, one wpa_supplicant, but with both ethernet/wifi=20 drivers > > > > >> loaded and active on their relevant interfaces.) _then_ we can=20 break > > > > >> out the "stuff devd does" out of netif and have _either_ netif=20 (x)or > > > > >> devd call this new script to setup/teardown the interface runtime > > > > >> state. > > > > >> > > > > >> How's that sound? > > > > > > > > > > Note that devd just runs netif (via /etc/pccard_ether), so it's=20 already > > > > > just one script, and having netif bail if devd is running would m= ake > > > > > netif not do anything in the common case. > > > > > > > > > > What normally happens during boot is that '/etc/rc.d/netif start'= =20 creates > > > > > wlan0 and runs wpa_supplicant via 'childif_create' making a neste= d=20 call to > > > > > ifn_start for wlan0. That is, childif_create autoruns=20 /etc/rc.d/netif > > > > > explicitly after it creates the device. Probably that is what=20 should be > > > > > removed. That would let devd always start wpa_supplicant via > > > > > /etc/pccard_ether. I've just tested this by doing a stop/start o= n=20 iwn0 > > > > > (parent of wlan0, so wlan0 gets destroyed and re-created) and it= =20 started > > > > > wpa_supplicant correctly. > > > > > > > > > > Index: head/etc/network.subr > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > --- network.subr (revision 257705) > > > > > +++ network.subr (working copy) > > > > > @@ -1429,9 +1429,6 @@ childif_create() > > > > > fi > > > > > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > > > > > fi > > > > > - if autoif $child; then > > > > > - ifn_start $child > > > > > - fi > > > > > done > > > > > > > > > > # Create vlan interfaces > > > > > > > > > > I also tested vlans created via vlans_ and they should use th= e=20 same fix as > > > > > well. Note that this model is more consistent with how=20 cloned_interfaces > > > > > works where ifn_start is not explicitly run when each interface i= s=20 created. > > > > > Instead, we rely on devd kicking off pccard_ether for those as we= ll. > > > >=20 > > > > That looks sane too me. > > > >=20 > > > > Just one question, I remember that devd is disabled during boot and > > > > activated later through a sysctl (to ignore events entirely), is th= is > > > > the case before or after netif is running? I guess it is activated > > > > after netif, otherwise we would have seen this issue on booting and > > > > not just during netif restart. > > >=20 > > > Hmm, devd starts after netif, but it just worked fine for me when I=20 booted up. > > > I also misspoke about cloned_interfaces. We manually add the=20 cloned_interface > > > list to the list of interfaces /etc/rc.d/netif iterates over. What I= am > > > puzzled by is that this just worked for me during a test boot. Hmm, = it=20 looks like > > > devctl is no longer disabled during boot and then explicitly enabled = by=20 devd. > > > devctl is now always enabled during boot, but capped at 1000 entries = to=20 avoid > > > leaking memory. In fact, it looks like devd tries to recreate a few= =20 interfaces > > > after netif finishes and is generally confused. I tried again with=20 devd_flags > > > set to "-n" to flush the initial set of events on boot. This removed= =20 the > > > multiple calls to netif on boot on my laptop, but somehow wpa_supplic= ant=20 is > > > still being started by devd (and I'm not sure how now). > >=20 > > I've hacked devd some more and can now see what is going on. -n doesn'= t=20 do what > > I thought it does. It does not throw away pending events on startup, i= t=20 just > > makes devd not fork until it has walked the initial set of events. The= =20 kernel > > changed (a while ago) to queue the first 1000 events until devd starts = up. =20 This > > means that in practice devd gets arrival events for all devices in the= =20 system as > > soon as it starts up and triggers duplicate invocations of netif after= =20 netif > > finishes. However, /etc/pccard_ether ignores attempts to start a devic= e=20 that > > is already up, so this should be a no-op on bootup (if my change is=20 reverted) > > as the interfaces should already be configured by the time devd starts.= I=20 suspect > > what happens in multiuser is that devd fires off pccard_ether and sees= =20 that the > > interface isn't up before the original netif has a chance to invoke the= =20 nested > > ifn_start. We could perhaps change it so we only invoke ifn_start if d= evd > > isn't running. > >=20 > > One other thought: I restart my wireless interfaces by doing > > 'sh /etc/rc.d/netif restart wlan0', not 'iwn0'. This doesn't=20 teardown/recreate > > the wlan0 device, so it doesn't suffer from the issue reported by the O= P. > >=20 > > Here is a change I've tested that seems to do the right thing both at b= oot=20 time > > and doing a restart of either iwn0 or wlan0 at runtime. If devd is=20 running > > it leaves the task of starting an interface up to devd, otherwise (such= as=20 during > > boot), it configures the new child interface synchronously. > >=20 > > Note that pgrep is in /bin. > >=20 > > Index: network.subr > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- network.subr (revision 257747) > > +++ network.subr (working copy) > > @@ -1406,10 +1406,14 @@ clone_down() > > # > > childif_create() > > { > > - local cfg child child_vlans child_wlans create_args debug_flags ifn i > > + local cfg child child_vlans child_wlans create_args debug_flags devd \ > > + ifn i > > cfg=3D1 > > ifn=3D$1 > > =20 > > + # Check if devd is running > > + devd=3D$(pgrep devd) > > + > > # Create wireless interfaces > > child_wlans=3D`get_if_var $ifn wlans_IF` > > =20 > > @@ -1429,6 +1433,9 @@ childif_create() > > fi > > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > > fi > > + if [ -z "$devd" ] && autoif $child; then > > + ifn_start $child > > + fi > > done > > =20 > > # Create vlan interfaces > > @@ -1452,6 +1459,9 @@ childif_create() > > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > > fi > > fi > > + if [ -z "$devd" ] && autoif $child; then > > + ifn_start $child > > + fi > > done > > =20 > > return ${cfg} > >=20 >=20 > Yes, the "service netif restart wlan0" doesn't teardown/recreate the > wlan0 device. Anyway, a "service netif restart" does. >=20 > What about removing this functionality, instead? See the patch below. >=20 > The pros: > 1) creating the wlan interface by hand (by ifconfig) means that the > further configuration is going to be in that way, by hand (by ifconfig, > route, dhcpclient, etc). > 2) already written down configuration (in rc.conf) means working with rc > subsystem (netif) > 3) I have no idea why somebody would expect from a command "ifconfig > wlan0 create wlandev ath0" the same behaviour as from a "service netif > start wlan0". Eh, I work with vlans quite a bit at work and I certainly do a model where I edit rc.conf and then create it by hand to bring it up. This is one less step than having to manually ifconfig it after creating it and then going to write to rc.conf. > 4) Let's remove the unexpected behaviour at all, it's prone error, it's > not obviously at first glance, some kind of clever computer which knows > better what do you need. I think that we have this functionality > occasionally, no one had designed this on purpose, am I wrong? I don't agree. > The cons: > I have none. You told me. >=20 >=20 > =CE=9E ~ =E2=86=92 diff -u /usr/src/etc/devd.conf /etc/devd.conf =20 > --- /usr/src/etc/devd.conf 2013-09-29 17:24:16.759250174 +0300 > +++ /etc/devd.conf 2013-11-07 23:43:17.833616197 +0200 > @@ -38,7 +38,7 @@ > # > notify 0 { > match "system" "IFNET"; > - match "subsystem" "!usbus[0-9]+"; > + match "subsystem" "!(usbus|wlan|vlan)[0-9]+"; > match "type" "ATTACH"; > action "/etc/pccard_ether $subsystem start"; > }; This isn't complete at all. Now you need to exclude everything, because what if I do 'ifconfig tap0 create' by hand? Now do you expect it to not configure that if I have bits for it in rc.conf? The usbus example here is because usbus isn't a real ifnet, but an abuse of the subsystem. wlanX and vlanX are real interfaces, they are just clone interfaces similar to tap/tun, etc. rather than "physical" interfaces liek bge0, etc. Everyone expects bge0 to auto configure if you pop in a bge cardbus card or kldload the driver. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:48:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA2A2A0E; Mon, 11 Nov 2013 20:48:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 8E56C2625; Mon, 11 Nov 2013 20:48:24 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 0B80E58391; Mon, 11 Nov 2013 14:48:24 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id QtRblLhhATOM; Mon, 11 Nov 2013 14:48:23 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id D49B65838F; Mon, 11 Nov 2013 14:48:23 -0600 (CST) Message-ID: <52814297.8050209@freebsd.org> Date: Mon, 11 Nov 2013 14:48:23 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" , Current Current , "Teske, Devin" , Peter Grehan , Michael Dexter X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:48:24 -0000 On 11/11/13 14:44, Teske, Devin wrote: > On Nov 11, 2013, at 12:30 PM, Nathan Whitehorn wrote: > >> On 11/11/13 14:18, Teske, Devin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> >>> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>> >>> >>> Hello all, >>> >>> I have been experimenting with various BSD and GNU/Linux boot media >>> under bhyve and noticed that we may want to accommodate the "LiveCD" >>> mode of the installer, which in turn requires the correct console. >>> >>> Currently, one is prompted for VT100 for installation but this does not >>> appear to work/stick for LiveCD mode. >>> >>> Can anyone verify this? >>> >>> >>> While I developed this patch... >>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascripts%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=3e5345ea6b13f84e719068bb993b66978f1971b648b430edfde9165677c279de >>> >>> Reasons exist to search for a better solution, see here: >>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=9ebff0354adb2634006e52cb4c0048287b7518bd7f4defe420ce5f34675ce5cd >>> (and messages that follow it) >>> >>> Is modifying init(8) still the way to go? What modification do we want to make? >>> I'll do the work if we can come to consensus. >>> >>> Or should we touch up the patch in some way to address the original concerns? >>> >> I think modifying init is the way to go -- it keeps the install system from interfering with the installed one, as well as fixing this kind of issue with moved hard drives or PXE booting or what have you. If we can provide a guarantee that any system that displays text has a working console (unless explicitly configured not to), useability is improved. >> >> I would propose one of the following (and volunteer to write the code): >> >> Option A >> ------------ >> >> 1. init checks if there is an entry in /etc/ttys for the terminal[s] corresponding to the value[s] in kern.console > Is kern.console set by bhyve while NULL or unset when booting from > a physical PC (bare metal)? It's set by the kernel console probe sequence and so is portable. If you see boot messages, then it worked. > >> 2. If an entry for each console terminal exists in /etc/ttys, enable it >> 3. If not, invent one with a terminal type of "ansi" >> >> The one issue here is that someone may want to force a particular entry to off and still have it be the kernel console. This is tricky. We could invent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifconsole"?). Which brings us to: >> > Trying to think of an edge-case where they would want to force it to off. > If the kern.console setting is only expected to be set via ... help me out here... > > + bhyve ? > + pxe ? > + what else ? > > Then maybe the secret sauce shouldn't be in /etc/ttys, but in the value that > is passed in via kern.console (that is, ... of the above ruminated technologies > which allow you to customize the value?) kern.console is a read-only variable (it's a struct, actually) set by the kernel. It reflects the state of the kernel console mechanism. The reason you might want to turn it off is if you want to use a machine that boots over serial temporarily as a console for another one (e.g. if a serial-only machine happens to be the only device you have with a serial port at that particular moment). It's an unusual case, but I've done it. > >> Option B >> ----------- >> >> Very similar to Option A, except only provide an automatic console using (2) and (3) if the "console" terminal is marked "on". This would increase the magic attached to "console" in /etc/ttys, but fix the problem with (A). >> >> It's possible another approach would work as well. Does anyone have thoughts on this? > If I'm not wrong, there's a third Option C that skirts the issue by bolstering the ability > to change things for different needs. > > That prior change that I had made to bsdinstall/scripts/config (iirc) was a big agressive > because it tried to automatically figure things out. > > If we simply made it a choice (a scriptable one), then that would solve the problem for > the installation. > > But for the LiveCD issue (Michael wants to bring up the installer's LiveCD via serial), > then perhaps we could solve it by using unionfs in the installer to make the install > environment writable (and again, change on-the-fly for different needs). > > Just a thought. Tell me if it's not an option ;D I won't mind. I'd really prefer not to have unionfs. To begin with, our unionfs mostly doesn't work, but my major objection is that it makes the install CDs magical. It's hard to replicate that in the analogous situation where you have moved a disk to a new machine or are PXE booting. -Nathan From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:54:56 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EBBC4E8E; Mon, 11 Nov 2013 20:54:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id A0B9126AB; Mon, 11 Nov 2013 20:54:55 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 2669858392; Mon, 11 Nov 2013 14:54:55 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 1lmZIlXGkq+0; Mon, 11 Nov 2013 14:54:55 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id E9C2458391; Mon, 11 Nov 2013 14:54:54 -0600 (CST) Message-ID: <5281441E.7060806@freebsd.org> Date: Mon, 11 Nov 2013 14:54:54 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske , Michael Dexter , "freebsd-arch@freebsd.org" , "freebsd-current@freebsd.org" , Peter Grehan Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: <52813E53.20403@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:54:56 -0000 On 11/11/13 14:30, Nathan Whitehorn wrote: > On 11/11/13 14:18, Teske, Devin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> >> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >> >> >> Hello all, >> >> I have been experimenting with various BSD and GNU/Linux boot media >> under bhyve and noticed that we may want to accommodate the "LiveCD" >> mode of the installer, which in turn requires the correct console. >> >> Currently, one is prompted for VT100 for installation but this does not >> appear to work/stick for LiveCD mode. >> >> Can anyone verify this? >> >> >> While I developed this patch... >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10&view=markup >> >> >> Reasons exist to search for a better solution, see here: >> http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html >> >> (and messages that follow it) >> >> Is modifying init(8) still the way to go? What modification do we >> want to make? >> I'll do the work if we can come to consensus. >> >> Or should we touch up the patch in some way to address the original >> concerns? >> > > I think modifying init is the way to go -- it keeps the install system > from interfering with the installed one, as well as fixing this kind > of issue with moved hard drives or PXE booting or what have you. If we > can provide a guarantee that any system that displays text has a > working console (unless explicitly configured not to), useability is > improved. > > I would propose one of the following (and volunteer to write the code): > > Option A > ------------ > > 1. init checks if there is an entry in /etc/ttys for the terminal[s] > corresponding to the value[s] in kern.console > 2. If an entry for each console terminal exists in /etc/ttys, enable it > 3. If not, invent one with a terminal type of "ansi" > > The one issue here is that someone may want to force a particular > entry to off and still have it be the kernel console. This is tricky. > We could invent a new "status" field that is not "on" or "off" > ("auto", maybe, or "ifconsole"?). Which brings us to: One easy way to accomplish this is just to only implement (1) and (3), then comment out the ttyu0 entry in /etc/ttys on x86 instead of marking it "off". Then the behavior is just that a tty marked "off" stays off, one marked "on" stays on, and one not present spawns login with a terminal type corresponding to "console" (by default "unknown") if it happens to be the console. I will implement this over the next few days and then send patches unless anyone has an objection. -Nathan From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:57:08 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B7A91F3; Mon, 11 Nov 2013 20:57:08 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF5226D4; Mon, 11 Nov 2013 20:57:08 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKv6H0026518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:57:07 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:57:05 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:57:04 +0000 Message-ID: References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> <5281441E.7060806@freebsd.org> In-Reply-To: <5281441E.7060806@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <487C3101B60CC24E98DABF63D8F8D01A@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: "Teske, Devin" , Current Current , "freebsd-arch@freebsd.org" , Devin Teske , Peter Grehan , Michael Dexter X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:57:08 -0000 On Nov 11, 2013, at 12:54 PM, Nathan Whitehorn wrote: > On 11/11/13 14:30, Nathan Whitehorn wrote: >> On 11/11/13 14:18, Teske, Devin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>=20 >>>=20 >>> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>>=20 >>>=20 >>> Hello all, >>>=20 >>> I have been experimenting with various BSD and GNU/Linux boot media >>> under bhyve and noticed that we may want to accommodate the "LiveCD" >>> mode of the installer, which in turn requires the correct console. >>>=20 >>> Currently, one is prompted for VT100 for installation but this does not >>> appear to work/stick for LiveCD mode. >>>=20 >>> Can anyone verify this? >>>=20 >>>=20 >>> While I developed this patch... >>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.sf.net= /viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascrip= ts%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=3D%2FbkpAUdJWZui= TILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DaZg%2Bxwq= LTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=3D6d54d337ea5472f5713ddbe7788d= 3248c45feefd4b291eab0a976c39e9d40428=20 >>>=20 >>> Reasons exist to search for a better solution, see here: >>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/p= ipermail/freebsd-current/2013-November/046148.html&k=3D%2FbkpAUdJWZuiTILCq%= 2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DaZg%2BxwqLTX6Zc= pf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=3D5f8128901747346f937ffc4478eadb4bc3= 9059504258dfb9b36f0fb9e7a61b79=20 >>> (and messages that follow it) >>>=20 >>> Is modifying init(8) still the way to go? What modification do we want = to make? >>> I'll do the work if we can come to consensus. >>>=20 >>> Or should we touch up the patch in some way to address the original con= cerns? >>>=20 >>=20 >> I think modifying init is the way to go -- it keeps the install system f= rom interfering with the installed one, as well as fixing this kind of issu= e with moved hard drives or PXE booting or what have you. If we can provide= a guarantee that any system that displays text has a working console (unle= ss explicitly configured not to), useability is improved. >>=20 >> I would propose one of the following (and volunteer to write the code): >>=20 >> Option A >> ------------ >>=20 >> 1. init checks if there is an entry in /etc/ttys for the terminal[s] cor= responding to the value[s] in kern.console >> 2. If an entry for each console terminal exists in /etc/ttys, enable it >> 3. If not, invent one with a terminal type of "ansi" >>=20 >> The one issue here is that someone may want to force a particular entry = to off and still have it be the kernel console. This is tricky. We could in= vent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifc= onsole"?). Which brings us to: >=20 > One easy way to accomplish this is just to only implement (1) and (3), th= en comment out the ttyu0 entry in /etc/ttys on x86 instead of marking it "o= ff". Then the behavior is just that a tty marked "off" stays off, one marke= d "on" stays on, and one not present spawns login with a terminal type corr= esponding to "console" (by default "unknown") if it happens to be the conso= le. I will implement this over the next few days and then send patches unle= ss anyone has an objection. I love it. (smiles) Excellent idea and that's the winner I think. +1 --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Tue Nov 12 04:48:17 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA609F85; Tue, 12 Nov 2013 04:48:17 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A49D3E70; Tue, 12 Nov 2013 04:48:13 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id rAC4lr8L062173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Nov 2013 13:48:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id rAC4lpo8042403; Tue, 12 Nov 2013 13:47:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 12 Nov 2013 13:47:42 +0900 (JST) Message-Id: <20131112.134742.1669584178551946391.hrs@allbsd.org> To: jhb@FreeBSD.org Subject: Re: service netif restart [iface] runs a wpa_supplicant twice From: Hiroki Sato In-Reply-To: <201311051154.18872.jhb@freebsd.org> References: <1383419596.3253.42.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Nov_12_13_47_42_2013_488)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 12 Nov 2013 13:48:04 +0900 (JST) X-Spam-Status: No, score=-98.8 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,SPF_SOFTFAIL,USER_IN_WHITELIST,X_CHINESE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: clutton@zoho.com, adrian@FreeBSD.org, freebsd-wireless@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 04:48:18 -0000 ----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Baldwin wrote in <201311051154.18872.jhb@freebsd.org>: jh> I also tested vlans created via vlans_ and they should use the same fix as jh> well. Note that this model is more consistent with how cloned_interfaces jh> works where ifn_start is not explicitly run when each interface is created. jh> Instead, we rely on devd kicking off pccard_ether for those as well. No, for cloned_interfaces, the ifn_start will be kicked even when devd is unavailable because rc.d/netif calls clone_up() and then ifn_start() sequentially. Since an IFNET ATTACH event is generated upon clone_up(), so actually the ifn_start() runs twice on every boot time (or rc.d/netif restart ifn). Since childif_*() is invoked at the end of ifn_*(), configuration of the child interfaces does not happen. This is the reason why there was ifn_start() in childif_create(). It is not efficient and it is reasonable to leave ifn_start() to devd if available, but it is difficult to detect it correctly because the IFNET ATTACH handler may be disabled in devd.conf. "pgrep devd" is not reliable enough. As pointed out, this duplication can be a problem when configuration is performed by a program because multiple instances of the program are invoked. In the other cases, there is no problem because ifn_start() is idempotent, though. As a workaround, dhclient is not invoked from ifconfig_up() like this: 222 if wpaif $1; then 223 /etc/rc.d/wpa_supplicant start $1 224 _cfg=0 # XXX: not sure this should count 225 elif hostapif $1; then 226 /etc/rc.d/hostapd start $1 227 _cfg=0 228 fi 229 230 if dhcpif $1; then 231 if [ $_cfg -ne 0 ] ; then 232 ${IFCONFIG_CMD} $1 up 233 fi 234 if syncdhcpif $1; then 235 /etc/rc.d/dhclient start $1 236 fi 237 _cfg=0 238 fi ifconfig_IF="DHCP" means to leave invoking dhclient to devd, and ifconfig_IF="SYNCDHCP" means rc.d/netif calls dhclient directly. I think similar workaround can be implemented for WPA and HOSTAP and solve the originally-reported problem. For inconsistency childif_*(), what do you think about integrating vlans_IF and wlans_IF into cloned_interfaces and removing the childif_*() stage in ifn_*()? We can keep vlans_IF and wlans_IF as well as introduce a new syntax into cloned_interfaces like cloned_interfaces="em0.100 em0.110 em0.myvlan ath0.wlan0" which is equivalent to vlans_em0="100 110 myvlan" wlans_ath0="wlan0" The rc.d/netif does clone_up() for the child interfaces first and then does ifn_start() for them, so # service netif restart wlan0 works as expected (tear down, recreate, and reconfigure the interface). Of course, this does not solve the duplicate invocation of the netif script. To solve it, I think we need a knob to disable IFNET events in a per-interface basis temporarily. -- Hiroki ----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlKBsu4ACgkQTyzT2CeTzy37MQCgpHsiUmxgrWJT9xbljklDRJPR r0wAnRdU90LfIZn7mgQFEwvNB42WZMGs =LYHy -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)---- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 12 19:54:57 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E17AF462; Tue, 12 Nov 2013 19:54:57 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1682F213F; Tue, 12 Nov 2013 19:54:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 11F4BB918; Tue, 12 Nov 2013 14:54:56 -0500 (EST) From: John Baldwin To: Hiroki Sato Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Tue, 12 Nov 2013 13:54:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1383419596.3253.42.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> <20131112.134742.1669584178551946391.hrs@allbsd.org> In-Reply-To: <20131112.134742.1669584178551946391.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201311121354.03923.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 12 Nov 2013 14:54:56 -0500 (EST) Cc: clutton@zoho.com, adrian@freebsd.org, freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:54:58 -0000 On Monday, November 11, 2013 11:47:42 pm Hiroki Sato wrote: > John Baldwin wrote > in <201311051154.18872.jhb@freebsd.org>: > > jh> I also tested vlans created via vlans_ and they should use the same fix as > jh> well. Note that this model is more consistent with how cloned_interfaces > jh> works where ifn_start is not explicitly run when each interface is created. > jh> Instead, we rely on devd kicking off pccard_ether for those as well. > > No, for cloned_interfaces, the ifn_start will be kicked even when > devd is unavailable because rc.d/netif calls clone_up() and then > ifn_start() sequentially. Since an IFNET ATTACH event is generated > upon clone_up(), so actually the ifn_start() runs twice on every boot > time (or rc.d/netif restart ifn). Yes, I missed this earlier. > Since childif_*() is invoked at the end of ifn_*(), configuration of > the child interfaces does not happen. This is the reason why there > was ifn_start() in childif_create(). Well, the child interfaces are not listed in list_network_interfaces. That explicitly adds cloned_interfaces to the list. > It is not efficient and it is reasonable to leave ifn_start() to devd > if available, but it is difficult to detect it correctly because the > IFNET ATTACH handler may be disabled in devd.conf. "pgrep devd" is > not reliable enough. Agreed that it is not perfect, and I don't really like it. However, I assumed that people who leave devd enabled but disable the IFNET ATTACH handler must already know enough about what they are doing to fix this on their own. :) I think there are two common use cases that we should make work out of the box: 1) People who use devd with a stock devd.conf. 2) People who don't use devd at all. I'm not sure we need to support the case of people hacking up a custom devd.conf directly in the base system. > As pointed out, this duplication can be a problem when configuration > is performed by a program because multiple instances of the program > are invoked. In the other cases, there is no problem because > ifn_start() is idempotent, though. Yes. One thought I had was to just fix /etc/rc.d/wpa_supplicant so that it was idempotent. If wpa_supplicant is the only one that really needs fixing I would favor that fix as the simplest one. > For inconsistency childif_*(), what do you think about integrating > vlans_IF and wlans_IF into cloned_interfaces and removing the > childif_*() stage in ifn_*()? We can keep vlans_IF and wlans_IF as > well as introduce a new syntax into cloned_interfaces like > > cloned_interfaces="em0.100 em0.110 em0.myvlan ath0.wlan0" > > which is equivalent to > > vlans_em0="100 110 myvlan" > wlans_ath0="wlan0" > > The rc.d/netif does clone_up() for the child interfaces first and > then does ifn_start() for them, so > > # service netif restart wlan0 > > works as expected (tear down, recreate, and reconfigure the > interface). cloned_interfaces already supports vlans (em0.100, etc.). The problems I had when we used that were: 1) if_vlan was not implicitly loaded, so we always cloned a vlan999 dummy device to load it 2) If we stopped an interface (typically on kldunload of the base driver), the vlan interfaces were orphaned. They stayed around, but with no parent. If a newer version of the driver was loaded via kldload, the vlan interfaces were not recreated. With vlans_IF, the right thing happens if you do 'stop foo0' and 'start foo0'. In particular if you do a 'stop foo0' before you kldunload foo, then all of foo0's subinterfaces are created and configured when you kldload foo. > Of course, this does not solve the duplicate invocation of the netif > script. To solve it, I think we need a knob to disable IFNET events > in a per-interface basis temporarily. Eh, I thought about doing some hackish thing to do that, but it seemed even more fragile and gross than the 'pgrep devd' hack. In particular, you could do this in /etc/rc.d/devd: devd_precmd() { touch /tmp/disable_netif } devd_postcmd() { rm /tmp/disable_netif } rc.conf: devd_flags="-n" And have /etc/pccard_ether bail if /tmp/disable_netif exists. This would let devd drain through all the queued up events at boot ignoring any IFNET ATTACH events by having pccard_ether bail. -- John Baldwin