From owner-freebsd-jail@FreeBSD.ORG Sun Apr 29 02:00:47 2012 Return-Path: Delivered-To: freebsd-jail@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37CEA1065670; Sun, 29 Apr 2012 02:00:47 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id EBD6D8FC14; Sun, 29 Apr 2012 02:00:46 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa05 [127.0.0.1]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with SMTP id q3T20iFM001795; Sat, 28 Apr 2012 21:00:44 -0500 Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com with ESMTP id 14gvc5g0bs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 28 Apr 2012 21:00:44 -0500 Received: from [10.0.0.105] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 28 Apr 2012 21:00:42 -0500 MIME-Version: 1.0 (Apple Message framework v1257) From: Devin Teske In-Reply-To: <4F9C74B4.70308@FreeBSD.org> Date: Sat, 28 Apr 2012 19:00:40 -0700 Message-ID: <45330131-E805-4590-8973-972073FC6EB8@fisglobal.com> References: <4F99AB0E.4090805@FreeBSD.org> <4F9B6E8F.8070708@erdgeist.org> <4F9C00E2.3070205@FreeBSD.org> <4F9C74B4.70308@FreeBSD.org> To: Jamie Gritton X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-28_07:2012-04-27, 2012-04-28, 1970-01-01 signatures=0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-Jail Subject: Re: New jail(8) committed X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 02:00:47 -0000 On Apr 28, 2012, at 3:52 PM, Jamie Gritton wrote: > I don't know about wrapping a utility around it, but it would be nice to > have in a library. If it could be made to work for not only jail, but > apmd and devd as well, then we could make some existing code cleaner. >=20 I'm thinking about throwing "figpar" into the CVS projects tree and then creating a few examples for reading jail.conf, apmd.conf, and devd.conf as well as dhcpd.conf. Naturally, this would be a library that you load and then pass it a struct-= array describing how you're going to handle the config file directives and what they look like. You're passing function pointers in the struct array and the parse_config() function will call the functions you pass to handle keywords. The header file (figpar.h) is 123 lines and the source file (figpar.c) is 3= 76 lines. There's only 2 functions and one struct to learn. The 2 functions ar= e: config_t* get_config_option(config_t [], char *); int parse_config(config_t [], char *, int (*)(u_int32_t, char *, char *)); NOTE: It will of course have to be cleaned up for style(9) compatibility (that's where the ``dusting off'' part comes-in). A link to the sources that I've uploaded temporarily to sourceforge (again, if we're serious about needing a light-weight parser for this file-format, I think we should import it into cvs:projects/figpar/ and hack on it together= ): http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/figpar/ --=20 Devin >=20 >=20 > On 04/28/12 10:52, Devin Teske wrote: >> On Apr 28, 2012, at 7:38 AM, Jamie Gritton wrote: >>=20 >>> The main reason I didn't consider a jail.d approach is just that I >>> haven't - such things are a little off the radar for me. It seemed very >>> natural to use a configuration file format that other programs already >>> use (e.g. named, apmd, devd). I suppose it's true that the "foo.d" >>> approach is also in use by other programs, though I mostly seem to see >>> those on Linux. And if I did opt for a directory approach, the files >>> within the directory would still need a format - you can't get away from >>> the fact that a config file needs a format. >>>=20 >>> It would be nice to have a general parser for C-style config files, and >>> I looked for such a library when I started on this. But such a library >>> doesn't seem to exist.Perhaps it's time to make one. >>>=20 >>=20 >> The config file format that you've chosen is remarkably identical to con= fig files for which I've already written parsers. >>=20 >> So, I guess I'm saying that I'm willing to help out in this area. >>=20 >> My parser is written in C, it's very small and light-weight, and it's ca= lled figpar (con[fig par]ser). >>=20 >> I can dust if off, slap a BSD license on it, wrap a utility around it an= d we could have something like sysrc (which operates on the collection of r= c.conf(5) files). >>=20 >> Alternatively, I could rewrite it in something like sh(1) if C is not de= sired. _____________ 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.