From owner-freebsd-hackers@FreeBSD.ORG Mon May 1 19:16:38 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 418C216A457 for ; Mon, 1 May 2006 19:16:38 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E7BA43D62 for ; Mon, 1 May 2006 19:16:09 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k41JG43q086024; Mon, 1 May 2006 14:16:05 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44565E74.3060801@centtech.com> Date: Mon, 01 May 2006 14:16:04 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060402) MIME-Version: 1.0 To: Brooks Davis References: <4447D2F7.1070408@centtech.com> <346a80220604232037mb6f98a0x5fab21622de5ce3c@mail.gmail.com> <444C51BA.3020905@centtech.com> <20060424131508.GB23163@pint.candc.home> <444CD48A.4060501@centtech.com> <444CE475.30104@centtech.com> <20060430231621.GA551@pint.candc.home> <44557F34.3020906@centtech.com> <20060501190645.GB4315@odin.ac.hmc.edu> <44565DD2.1020604@centtech.com> <20060501191447.GD4315@odin.ac.hmc.edu> In-Reply-To: <20060501191447.GD4315@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1433/Mon May 1 03:10:05 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: hackers@freebsd.org, Coleman Kane Subject: Re: [PATCH] Fancy rc startup style RFC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 19:16:38 -0000 Brooks Davis wrote: > On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: >> Brooks Davis wrote: >>> On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: >>>> Coleman Kane wrote: >>>>> On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: >>>>>> Eric Anderson wrote: >>>>>> >>>>>> Actually, some other things got changed somewhere in the history, that >>>>>> broke some things and assumptions I was making. This patch has them >>>>>> fixed, and I've tested it with all the different options: >>>>>> >>>>>> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 >>>>>> >>>>>> It's missing the defaults/rc.conf diffs, but you should already know >>>>>> those. >>>>>> >>>>>> >>>>>> Eric >>>>>> >>>>> I have a new patch (to 7-CURRENT) of the "fancy_rc" updates. >>>>> >>>>> This allows the use of: >>>>> rc_fancy="YES" ---> Turns on fancy reporting (w/o color) >>>>> rc_fancy_color="YES" ---> Turns on fancy reporting (w/ color), needs >>>>> rc_fancy="YES" >>>>> rc_fancy_colour="YES" ---> Same as above for you on the other side of >>>>> the pond. >>>>> rc_fancy_verbose="YES" --> Turn on more verbose activity messages. >>>>> This will cause what appear to be "false >>>>> positives", where an unused service is >>>>> "OK" instead of "SKIP". >>>>> >>>>> You can also customize the colors, the widths of the message >>>>> brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and >>>>> the contents of the message (OK versus GOOD versus BUENO). >>>>> >>>>> Also, we have the following message combinations: >>>>> OK ---> Universal good message >>>>> SKIP,SKIPPED ---> Two methods for conveying the same idea? >>>>> ERROR,FAILED ---> Ditto above, for failure cases >>>>> >>>>> Should we just have 3 different messages, rather than 5 messages >>>>> in 3 categories? >>>> Yes, that's something that started with my first patch, and never got >>>> ironed out. I think it should be: >>>> OK >>>> SKIPPED >>>> FAILED >>>> and possibly also: >>>> ERROR >>>> >>>> The difference between FAILED and ERROR would be that FAILED means the >>>> service did not start at all, and ERROR means it started but had some >>>> kind of error response. >>> FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs >>> FAILED or ERROR. >> True, however I still see a difference between FAILED and WARNING. For >> instance, as an example: a FAILED RAID is different than a RAID with a >> WARNING. > > For that level of detail, the ability to provide additional output seems > like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------