Date: Fri, 18 Nov 2011 21:37:19 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Eygene Ryabinkin <rea@freebsd.org> Cc: freebsd-rc@freebsd.org, mtm@freebsd.org, Doug Barton <dougb@freebsd.org>, d@delphij.net Subject: Re: Annoying ERROR: 'wlan0' is not a DHCP-enabled interface Message-ID: <CAGH67wQdmLnQ6dS7iTan3s1x7%2B2HVuAJqBPCcPspzWhpD%2BDqPA@mail.gmail.com> In-Reply-To: <3EG8fAEe6lZEtr/D6Pw60YTcoYU@YnbH/K3/Y1Z96RV2jTofcGuSPJI> References: <4EC6C9A4.3000006@delphij.net> <CAGH67wRBBtKm5K8iNPpB2_JGwFnxL4Gif1gMxR0sPe=bro4Jdw@mail.gmail.com> <3EG8fAEe6lZEtr/D6Pw60YTcoYU@YnbH/K3/Y1Z96RV2jTofcGuSPJI>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/11/18 Eygene Ryabinkin <rea@freebsd.org>: > Gentlemen, good morning. > > Fri, Nov 18, 2011 at 12:59:08PM -0800, Garrett Cooper wrote: >> 2011/11/18 Eygene Ryabinkin <rea@freebsd.org>: >> > Well, what about the silent output from 'cc -o test test.c' when >> > you have no file test.c or the compiler is absent? =A0It is the same >> > thing (as I see it) and in this case will you expect that the binary >> > 'test' will be compiled and ready for use or not? =A0I will, but this >> > can be my personal delusion. >> >> =A0 =A0 This is different because you personally are running cc to do a >> particular task. This noise is emitted unnecessarily by automated >> tasks which are in the default system, which is more annoying for >> standard users, like me. > > Hmm, automated tasks (devd in our case) run 'quietstart', not bare > 'start', so my latest patch that was announced for the testing > yesterday just tries to cope with this situation: no noise will be > produced for the 'quiest<op>', but bare '<op>' will spit a reason > for skipping DHCP client run on non-DHCP interface. =A0I believe that > this fits to your expectations: intended invocation via 'start' will > throw a verbose error, but automated one via 'quietstart' -- won't. > > So, we seem to be closer to some consensus, aren't we? Yes. My disagreement was more or less over the class of the error message (I agree that it should exist, but it seems more debug than something that should be printed on stdout for all cases). > Fri, Nov 18, 2011 at 01:09:56PM -0800, Xin LI wrote: >> On 11/18/11 12:45, Eygene Ryabinkin wrote: >> > Well, when I invoke 'service dhclient start em0' and em0 isn't >> > DHCP-enabled, I want to see some diagnostics on why I was not able >> > to get DHCP on that interface. =A0Return code isn't that visible (I >> > can, of course, always run it as 'service dhclient start em0 || >> > echo failed'), but I am not up to typing more than needed and I >> > should see the real reason for absence of DHCP-assigned address in >> > that case, be it the non-DHCP-enabled interface or some other >> > problem. >> >> Thinking again I believe that your approach is more sensible. >> Thanks! > > Thank you! > > So, seems like the only known caveat (raised by Doug) is the semantics > of the 'quiet' prefix. =A0Looking at the NetBSD CVS, > =A0http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.subr?annotate=3D1.88&on= ly_with_tag=3DMAIN > I see that they have no 'quiet' operations, so this is FreeBSD addition > made by mtm@, > =A0http://svnweb.freebsd.org/base?view=3Drevision&revision=3D175676 > Judging by that change and the fact that rc_quiet is mostly used > internally to the rc.subr and currently its only use is to skip > some diagnostics in the following snippet, > {{{ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if [ -n "${rcvar}" -a "$rc_arg" !=3D "rcva= r" -a "$rc_arg" !=3D "stop" ] || > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[ -n "${rcvar}" -a "$rc_arg" =3D "= stop" -a -z "${rc_pid}" ]; then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ! checkyesno ${rcvar}; = then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if [ -n "$= {rc_quiet}" ]; then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0return 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fi > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0echo -n "C= annot '${rc_arg}' $name. Set ${rcvar} to " > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0echo -n "Y= ES in /etc/rc.conf or use 'one${rc_arg}' " > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0echo "inst= ead of '${rc_arg}'." > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fi > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fi > }}} > > I would say that my (ab)use of it in the patch perfectly fits the > cited usage. =A0That's not an excuse if the semantics of rc_quiet will > be different from its current usage, but since we have no > well-documented semantics apart from "Don't output some diagnostics" > inside /etc/rc.subr, may be we can just extend this explanation based > on the current usage and the common sense, add that to the manual page > of rc.subr and go on? I'd say just do it. Otherwise the semantics of 'quiet' vs 'non-quiet' will be frittered over unnecessarily, when the original implementer should have just documented the requirements in an unambiguous manner. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wQdmLnQ6dS7iTan3s1x7%2B2HVuAJqBPCcPspzWhpD%2BDqPA>