From owner-freebsd-arch@FreeBSD.ORG Tue Jul 16 15:33:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DDBAE58; Tue, 16 Jul 2013 15:33:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 08C46E94; Tue, 16 Jul 2013 15:33:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56976B995; Tue, 16 Jul 2013 11:33:39 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT Date: Tue, 16 Jul 2013 11:30:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <201307121748.57778.jhb@freebsd.org> <20130713175835.GN91021@kib.kiev.ua> In-Reply-To: <20130713175835.GN91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307161130.40737.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Jul 2013 11:33:39 -0400 (EDT) Cc: arch@freebsd.org, "Robert N. M. Watson" , Jilles Tjoelker , 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: Tue, 16 Jul 2013 15:33:40 -0000 On Saturday, July 13, 2013 1:58:35 pm Konstantin Belousov wrote: > On Fri, Jul 12, 2013 at 05:48:57PM -0400, John Baldwin wrote: > > On Friday, June 28, 2013 2:46:01 pm John Baldwin wrote: > > > Ok, there isn't really a clear consensus here, but I need a system call to let > > > me toggle this flag on existing processes. > > > > > > One reason I don't like the procctl() approach is I am uneasy about forcing > > > a certain behavior for how commands treat pgid (first-fail vs best-effort). > > > I guess it can always change in the future so that isn't completely unsolvable. > > > > > > I guess I am fine just making it use hardcoded sizes instead of full-blown > > > ioctl encoding. > > > > Ok, I have updated patches for this for HEAD. I have not yet implemented the > > inheritance bits because I'm loathe to add the first bit to a p_flag2. :-P > > However, if that's the best course of action I suppose we can do that. > > > > The kernel patch is at www.freebsd.org/~jhb/patches/procctl.patch > > > > The patch for the protect binary is at www.freebsd.org/~jhb/patches/protect.patch > > > > It seems that p_cansee() is called twice, once in kern_procctl(), and > then in protect_setchild(). Yes, this is because protect_setchild() can descend to child processes, and you might not be able to "see" a child process if it exec'd a suid binary, etc. > Is AUE_WAIT6 the correct audit event id for procctl ? Nope. (It probably needs a new one?) > I thought proposing to use pget() for P_PID case in kern_procctl(), but > indeed open coding of the process lookup is easier, since otherwise > you would need to move proctree_lock acquisition to P_PGID. > > Why do you need PPROT_CLEAR ? If you do need the flag, would it be better > to assign a non-zero value to it ? I need it for 'protect -c' which is similar to 'ktrace -C'. That is, to allow protection to be removed from existing processes. I added a constant for it to make the code clear as the caller should pick one of PPROT_SET or PPROT_CLEAR (kind of like MAP_PRIVATE vs MAP_SHARED for mmap(2)). Otherwise you would have 'procctl(..., PROC_SPROTECT, 0)' which is not as obvious to me as ', PPROT_CLEAR)'. Also, you can do 'PPROT_CLEAR | PPROT_DESCEND' to clear it for all descendants. Having 'PPROT_SET | PPROT_DESCEND' to set it for descendenats and just 'PPROT_DESCEND' to clear for descendants doesn't seem as readable. Do you have any thoughts on p_flag2 (vs some other approach, possibly I should create a new field for oom-specific flags instead since we may eventually store a priority there?) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 16 17:16:53 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0BFBA53A; Tue, 16 Jul 2013 17:16:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 50440615; Tue, 16 Jul 2013 17:16:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6GHGmNF041582; Tue, 16 Jul 2013 20:16:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6GHGmNF041582 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6GHGm2x041581; Tue, 16 Jul 2013 20:16:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Jul 2013 20:16:48 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130716171648.GI5991@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <201307121748.57778.jhb@freebsd.org> <20130713175835.GN91021@kib.kiev.ua> <201307161130.40737.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Y7d0dPL928TPQbc" Content-Disposition: inline In-Reply-To: <201307161130.40737.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, "Robert N. M. Watson" , Jilles Tjoelker , 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: Tue, 16 Jul 2013 17:16:53 -0000 --1Y7d0dPL928TPQbc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 11:30:40AM -0400, John Baldwin wrote: > On Saturday, July 13, 2013 1:58:35 pm Konstantin Belousov wrote: > > On Fri, Jul 12, 2013 at 05:48:57PM -0400, John Baldwin wrote: > > > On Friday, June 28, 2013 2:46:01 pm John Baldwin wrote: > > > > Ok, there isn't really a clear consensus here, but I need a system = call to let > > > > me toggle this flag on existing processes. > > > >=20 > > > > One reason I don't like the procctl() approach is I am uneasy about= forcing > > > > a certain behavior for how commands treat pgid (first-fail vs best-= effort). > > > > I guess it can always change in the future so that isn't completely= unsolvable. > > > >=20 > > > > I guess I am fine just making it use hardcoded sizes instead of ful= l-blown > > > > ioctl encoding. > > >=20 > > > Ok, I have updated patches for this for HEAD. I have not yet impleme= nted the > > > inheritance bits because I'm loathe to add the first bit to a p_flag2= =2E :-P > > > However, if that's the best course of action I suppose we can do that. > > >=20 > > > The kernel patch is at www.freebsd.org/~jhb/patches/procctl.patch > > >=20 > > > The patch for the protect binary is at www.freebsd.org/~jhb/patches/p= rotect.patch > > >=20 > >=20 > > It seems that p_cansee() is called twice, once in kern_procctl(), and > > then in protect_setchild(). >=20 > Yes, this is because protect_setchild() can descend to child processes, a= nd > you might not be able to "see" a child process if it exec'd a suid binary= , etc. >=20 > > Is AUE_WAIT6 the correct audit event id for procctl ? >=20 > Nope. (It probably needs a new one?) Yes, probably needs a new id. > =20 > > I thought proposing to use pget() for P_PID case in kern_procctl(), but > > indeed open coding of the process lookup is easier, since otherwise > > you would need to move proctree_lock acquisition to P_PGID. > >=20 > > Why do you need PPROT_CLEAR ? If you do need the flag, would it be bet= ter > > to assign a non-zero value to it ? >=20 > I need it for 'protect -c' which is similar to 'ktrace -C'. That is, to > allow protection to be removed from existing processes. I added a consta= nt > for it to make the code clear as the caller should pick one of PPROT_SET > or PPROT_CLEAR (kind of like MAP_PRIVATE vs MAP_SHARED for mmap(2)). Oth= erwise > you would have 'procctl(..., PROC_SPROTECT, 0)' which is not as obvious > to me as ', PPROT_CLEAR)'. Also, you can do 'PPROT_CLEAR | PPROT_DESCEND' > to clear it for all descendants. Having 'PPROT_SET | PPROT_DESCEND' to s= et > it for descendenats and just 'PPROT_DESCEND' to clear for descendants doe= sn't > seem as readable. Well, I think that assigning non-zero value is justified. >=20 > Do you have any thoughts on p_flag2 (vs some other approach, possibly I > should create a new field for oom-specific flags instead since we may > eventually store a priority there?) p_flag2 is inevitable, it seems. It would be added now, or, even if you could avoid this, in the nearest future. I do not like mixing a flag and a priority-like field. --1Y7d0dPL928TPQbc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR5X//AAoJEJDCuSvBvK1B8u4P/RftpKukYPJgbQdOXJVsTk1r LVY5VqJQZfGHGd3xt5Oqzz+KPAmQvC8aX5cnU+KF+ISz9d2JDYvbZmjI3F7oHoYN /vvMw6tuNdnLs8Tf+TV8FEf6VvQYG7yCapMZ+D91YVQIA4igJz1vk+pNtW+QppBb klS/cvjHnVX8dzOPHj9iRroTF/CJA+9PF13GIbA+cZGi0nfubyhI/jlscOVm8LGt geyKn7vqlp4xOQSg2iOCYeMEl+dTpelRkRDemuoBtaNZq0xN+vokpaDUH651vNuk kCgljz+ENuBfzbp+x7i2/j5L7+cKPkdpzNaVTTWTMmE7GQ5G33yfTwrpgXTpo+Br n0SKkWf/ii5XJiF25HICBhEPXFMYrUhGNQMNbePTrYGg7N3/Apc31h2QutJ0Namu c9TBqLUYVl+3/EPZTsxv6tzbFULCjoNgzWdDSlu6r4/MRKFGX/xWKqkTw5TY9j02 h0ItB5DK3J0sAjIHNCRWP9i3eDc84m6x4+Ar4IQglYo4PEGtjEhAWQkaG/eXgkJn kuVg4/N5u2FjnDKYypY9n9s2I9p+vAwxbpEhXdtlM2NU6bDhvky0QonMOThVJDC/ Y+oRqgiHlYzjA11M1s/299HfEGfCoHF12FV/QQTiYyLAnknNH5tQqKTHLP++qmxF zJ+T4rDtHOWTLEHxq+s/ =OoaF -----END PGP SIGNATURE----- --1Y7d0dPL928TPQbc-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 16 22:06:24 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 849CC68A; Tue, 16 Jul 2013 22:06:24 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by mx1.freebsd.org (Postfix) with ESMTP id E94305EA; Tue, 16 Jul 2013 22:06:23 +0000 (UTC) Received: from mail40-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE041.bigfish.com (10.174.14.104) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 22:06:21 +0000 Received: from mail40-db9 (localhost [127.0.0.1]) by mail40-db9-R.bigfish.com (Postfix) with ESMTP id B7AD3540140; Tue, 16 Jul 2013 22:06:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch17326ah8275bh8275dhz2fh2a8h668h839h944hd24hd2bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1155h) Received-SPF: pass (mail40-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=stevek@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; Received: from mail40-db9 (localhost.localdomain [127.0.0.1]) by mail40-db9 (MessageSwitch) id 1374012379761135_19021; Tue, 16 Jul 2013 22:06:19 +0000 (UTC) Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.249]) by mail40-db9.bigfish.com (Postfix) with ESMTP id B09EF580048; Tue, 16 Jul 2013 22:06:19 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 16 Jul 2013 22:06:14 +0000 Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 16 Jul 2013 15:06:12 -0700 Date: Tue, 16 Jul 2013 18:06:06 -0400 From: Steve Kiernan To: Jordan Hubbard Subject: Re: General purpose library for name/value pairs. Message-ID: <20130716180606.55ec081c@stevek-ubuntu> In-Reply-To: <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: 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: Tue, 16 Jul 2013 22:06:24 -0000 On Mon, 8 Jul 2013 10:57:17 -0700 Jordan Hubbard wrote: > > On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek wrote: > > > How about instead of supporting int8, uint8, int16, uint16, int32, > > uint32, int64 and uint64 I'd just support 'number' type, which would be > > uint64_t. This shouldn't break transporting signed values and because I > > don't support basic types like int, long, etc. casting or conversion has > > to be done anyway. This would reduce number of supported types to: > > That's a good idea. Since you're re-inventing Apple's XML property list API (but without serialization and quite a few other things), keeping the number of supported types down is much better than the converse - exposing the details of 16/32/64 bit numbers and their signedness will hang you over the long term, and you can always provide explicit conversion functions to/from Number for those who actually care. > > String, Number, Boolean, Data, Date, Array and Dictionary are all plists support, and Apple developers have gotten along pretty well for many years with that set (not supporting Dictionaries, btw, is a pretty fundamental loss IMHO - it means you have to always iterate through lists to find your stuff, which is meh!). > > When Apple extended the Plist metaphor for IPC (to create XPC), they also added out-of-band types like file and shared memory descriptors. You have file descriptors, but not shared memory. The latter is kind of important if you want to do larger IPCs with this mechanism someday and want to support "big payloads" transparently without passing the burden of the data management to the application programmer. > > Before you also come back with "but but this is a kernel API! For just one purpose!" let me just say that it's absolutely achievable to have ONE API for talking userland<->kernel and userland<->userland with the same types and the transport mechanism(s) largely abstracted away. You don't need two - it's already been done with one, just look next door. :) > > If you add file serialization of this format to your picture (and add the dictionary type) , bingo, now you have a preferences API that FreeBSD has lacked from day one ("just roll your own format and stick the file in /etc" being the canonical response to that need). What about looking at NetBSD's libprop? PROPLIB(3) FreeBSD Library Functions Manual PROPLIB(3) NAME proplib -- property container object library LIBRARY library ``libprop'' SYNOPSIS #include DESCRIPTION The proplib library provides an abstract interface for creating and manipulating property lists. Property lists have object types for boolean values, opaque data, numbers, and strings. Structure is provided by the array and dictionary collection types. Property lists can be passed across protection boundaries by translating them to an external representation. This external representation is an XML document whose format is described by the following DTD: http://www.apple.com/DTDs/PropertyList-1.0.dtd Property container objects are reference counted. When an object is cre- ated, its reference count is set to 1. Any code that keeps a reference to an object, including the collection types (arrays and dictionaries), must ``retain'' the object (increment its reference count). When that reference is dropped, the object must be ``released'' (reference count decremented). When an object's reference count drops to 0, it is auto- matically freed. The rules for managing reference counts are very simple: o If you create an object and do not explicitly maintain a reference to it, you must release it. o If you get a reference to an object from other code and wish to main- tain a reference to it, you must retain the object. You are respon- sible for releasing the object once you drop that reference. o You must never release an object unless you create it or retain it. Object collections may be iterated by creating a special iterator object. Iterator objects are special; they may not be retained, and they are released using an iterator-specific release function. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net From owner-freebsd-arch@FreeBSD.ORG Tue Jul 16 22:39:35 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A94DAD77; Tue, 16 Jul 2013 22:39:35 +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 51E506D6; Tue, 16 Jul 2013 22:39:34 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r6GMdRUN003456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Jul 2013 17:39:34 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Tue, 16 Jul 2013 17:39:33 -0500 From: "Teske, Devin" To: Steve Kiernan Subject: Re: General purpose library for name/value pairs. Thread-Topic: General purpose library for name/value pairs. Thread-Index: AQHOeQDhn1IH8mH3sEeIpLvmIzmJnZlV/ouAgADVwICAAAT1AIAEYRIAgAAwqICADNgsAIAACViA Date: Tue, 16 Jul 2013 22:39:32 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC9EED@ltcfiswmsgmb21> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130716180606.55ec081c@stevek-ubuntu> In-Reply-To: <20130716180606.55ec081c@stevek-ubuntu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] 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-07-16_09:2013-07-16,2013-07-16,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "arch@freebsd.org" , Devin Teske , Jordan Hubbard 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: Tue, 16 Jul 2013 22:39:35 -0000 On Jul 16, 2013, at 3:06 PM, Steve Kiernan wrote: On Mon, 8 Jul 2013 10:57:17 -0700 Jordan Hubbard > wrot= e: On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek > wrote: How about instead of supporting int8, uint8, int16, uint16, int32, uint32, int64 and uint64 I'd just support 'number' type, which would be uint64_t. This shouldn't break transporting signed values and because I don't support basic types like int, long, etc. casting or conversion has to be done anyway. This would reduce number of supported types to: That's a good idea. Since you're re-inventing Apple's XML property list AP= I (but without serialization and quite a few other things), keeping the num= ber of supported types down is much better than the converse - exposing the= details of 16/32/64 bit numbers and their signedness will hang you over th= e long term, and you can always provide explicit conversion functions to/fr= om Number for those who actually care. String, Number, Boolean, Data, Date, Array and Dictionary are all plists su= pport, and Apple developers have gotten along pretty well for many years wi= th that set (not supporting Dictionaries, btw, is a pretty fundamental loss= IMHO - it means you have to always iterate through lists to find your stuf= f, which is meh!). When Apple extended the Plist metaphor for IPC (to create XPC), they also a= dded out-of-band types like file and shared memory descriptors. You have f= ile descriptors, but not shared memory. The latter is kind of important if= you want to do larger IPCs with this mechanism someday and want to support= "big payloads" transparently without passing the burden of the data manage= ment to the application programmer. Before you also come back with "but but this is a kernel API! For just one= purpose!" let me just say that it's absolutely achievable to have ONE API = for talking userland<->kernel and userland<->userland with the same types a= nd the transport mechanism(s) largely abstracted away. You don't need two = - it's already been done with one, just look next door. :) If you add file serialization of this format to your picture (and add the d= ictionary type) , bingo, now you have a preferences API that FreeBSD has la= cked from day one ("just roll your own format and stick the file in /etc" b= eing the canonical response to that need). What about looking at NetBSD's libprop? PROPLIB(3) FreeBSD Library Functions Manual PROPLIB= (3) NAME proplib -- property container object library LIBRARY library ``libprop'' SYNOPSIS #include DESCRIPTION The proplib library provides an abstract interface for creating and manipulating property lists. Property lists have object types for boolean values, opaque data, numbers, and strings. Structure is provid= ed by the array and dictionary collection types. Property lists can be passed across protection boundaries by translating them to an external representation. This external representation is an XML document whose format is described by the following DTD: http://www.apple.com/DTDs/PropertyList-1.0.dtd Property container objects are reference counted. When an object is cr= e- ated, its reference count is set to 1. Any code that keeps a reference to an object, including the collection types (arrays and dictionaries), must ``retain'' the object (increment its reference count). When that reference is dropped, the object must be ``released'' (reference count decremented). When an object's reference count drops to 0, it is auto- matically freed. The rules for managing reference counts are very simple: o If you create an object and do not explicitly maintain a reference = to it, you must release it. o If you get a reference to an object from other code and wish to mai= n- tain a reference to it, you must retain the object. You are respon- sible for releasing the object once you drop that reference. o You must never release an object unless you create it or retain it. Object collections may be iterated by creating a special iterator objec= t. Iterator objects are special; they may not be retained, and they are released using an iterator-specific release function. There's also my own "figpar" free for the taking... http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/figpar/ >From figpar.c dteske@scribe9.vicor.com figpar $ wc -l *.= h *.c 123 figpar.h 40 string_m.h 376 figpar.c 292 string_m.c 831 total I recently had to resurrect string_m.{c,h} for another project, and made th= em suitable for the FreeBSD tree: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/fdpv/ (if you're interested; really just pointing at string_m.{c,h}) I wrote figpar back in 2002 and it's pretty simple. It parses any POSIX style file and lets *you* (as the user of figpar) decid= e how different matches are handled. It indeed has what the OP was interest= ed in... Do X when you get NUM (instead of all separate types, etc.). >From figpar.h: =3D=3D=3D /* cfgvalue_t is a 4 byte union that allows you to store varied types of data in a single common container. */ typedef union { char *str; /* a pointer to a null terminated string */ int32_t num; /* a signed 32-bit integer value */ u_int32_t boolean:1; /* boolean integer value (0 or 1) */ u_int32_t u_num; /* an unsigned 32-bit integer value */ char **strarray; /* pointer to an array of strings */ } cfgvalue_t; =3D=3D=3D The OP would simply bump that union to 8 bytes and make the default "num" b= e a u_int64_t (not how there is also "u_num" etc.). The rest is pretty simple. Of the 499 lines that comprise figpar.h and figp= ar.c, there's only two typedefs to learn and two funtions to utilize. The r= est you bring to the table yourself (you add functions for handling directi= ves by "match" -- uses fnmatch(3) to match a configuration directive and fi= re your function). I've used this to parse pretty much any config file ever seen (from apache = httpd.conf to jail.conf-style configuration files). HINT: You can match on = "{" and implement a state/identifier-machine to implement groupings. What it does is remove all the nasty details of how to parse a file and let= you worry about what gets fired when it deems it's found a match to one of= your definitions. It also tries to keep things nice, as you pass it a struct-array of definit= ions (which I find helpful because I can have a nice block-definition that'= s centrally located for continuous munging). Sure, it'd need some style(9) application (I wrote it in 2002), but it's al= so extremely portable (tested successfully on over 4-dozen platforms). As you can see from the union above, it supports most types and you can ext= end it to support more. But in my experience, I've never needed more than t= hat basic set. Of course, as it is under 500 lines, it may not be as flexible as bison+yac= c, but it's never done me wrong (and pretty easy for any person on a distri= buted project to grasp and run-with). My 2 cents. -- 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 Jul 16 22:49:04 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2A08FEA; Tue, 16 Jul 2013 22:49:04 +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 7CDAB77E; Tue, 16 Jul 2013 22:49:04 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r6GMn37F024061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Jul 2013 17:49:03 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Tue, 16 Jul 2013 17:49:03 -0500 From: "Teske, Devin" To: Steve Kiernan Subject: Re: General purpose library for name/value pairs. Thread-Topic: General purpose library for name/value pairs. Thread-Index: AQHOeQDhn1IH8mH3sEeIpLvmIzmJnZlV/ouAgADVwICAAAT1AIAEYRIAgAAwqICADNgsAIAACViAgAACpwA= Date: Tue, 16 Jul 2013 22:49:02 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC9F3C@ltcfiswmsgmb21> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130716180606.55ec081c@stevek-ubuntu> <13CA24D6AB415D428143D44749F57D7201FC9EED@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC9EED@ltcfiswmsgmb21> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] 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-07-16_09:2013-07-16,2013-07-16,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "arch@freebsd.org" , Devin Teske , Jordan Hubbard 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: Tue, 16 Jul 2013 22:49:04 -0000 On Jul 16, 2013, at 3:39 PM, Teske, Devin wrote: On Jul 16, 2013, at 3:06 PM, Steve Kiernan wrote: On Mon, 8 Jul 2013 10:57:17 -0700 Jordan Hubbard > wrot= e: On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek > wrote: How about instead of supporting int8, uint8, int16, uint16, int32, uint32, int64 and uint64 I'd just support 'number' type, which would be uint64_t. This shouldn't break transporting signed values and because I don't support basic types like int, long, etc. casting or conversion has to be done anyway. This would reduce number of supported types to: That's a good idea. Since you're re-inventing Apple's XML property list AP= I (but without serialization and quite a few other things), keeping the num= ber of supported types down is much better than the converse - exposing the= details of 16/32/64 bit numbers and their signedness will hang you over th= e long term, and you can always provide explicit conversion functions to/fr= om Number for those who actually care. String, Number, Boolean, Data, Date, Array and Dictionary are all plists su= pport, and Apple developers have gotten along pretty well for many years wi= th that set (not supporting Dictionaries, btw, is a pretty fundamental loss= IMHO - it means you have to always iterate through lists to find your stuf= f, which is meh!). When Apple extended the Plist metaphor for IPC (to create XPC), they also a= dded out-of-band types like file and shared memory descriptors. You have f= ile descriptors, but not shared memory. The latter is kind of important if= you want to do larger IPCs with this mechanism someday and want to support= "big payloads" transparently without passing the burden of the data manage= ment to the application programmer. Before you also come back with "but but this is a kernel API! For just one= purpose!" let me just say that it's absolutely achievable to have ONE API = for talking userland<->kernel and userland<->userland with the same types a= nd the transport mechanism(s) largely abstracted away. You don't need two = - it's already been done with one, just look next door. :) If you add file serialization of this format to your picture (and add the d= ictionary type) , bingo, now you have a preferences API that FreeBSD has la= cked from day one ("just roll your own format and stick the file in /etc" b= eing the canonical response to that need). What about looking at NetBSD's libprop? PROPLIB(3) FreeBSD Library Functions Manual PROPLIB= (3) NAME proplib -- property container object library LIBRARY library ``libprop'' SYNOPSIS #include DESCRIPTION The proplib library provides an abstract interface for creating and manipulating property lists. Property lists have object types for boolean values, opaque data, numbers, and strings. Structure is provid= ed by the array and dictionary collection types. Property lists can be passed across protection boundaries by translating them to an external representation. This external representation is an XML document whose format is described by the following DTD: http://www.apple.com/DTDs/PropertyList-1.0.dtd Property container objects are reference counted. When an object is cr= e- ated, its reference count is set to 1. Any code that keeps a reference to an object, including the collection types (arrays and dictionaries), must ``retain'' the object (increment its reference count). When that reference is dropped, the object must be ``released'' (reference count decremented). When an object's reference count drops to 0, it is auto- matically freed. The rules for managing reference counts are very simple: o If you create an object and do not explicitly maintain a reference = to it, you must release it. o If you get a reference to an object from other code and wish to mai= n- tain a reference to it, you must retain the object. You are respon- sible for releasing the object once you drop that reference. o You must never release an object unless you create it or retain it. Object collections may be iterated by creating a special iterator objec= t. Iterator objects are special; they may not be retained, and they are released using an iterator-specific release function. There's also my own "figpar" free for the taking... http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/figpar/ >From figpar.c Sorry, meant to paste the explanation excerpt from figpar.c right there... /* figpar.c -------- figpar, the con-fig par-ser. heh This file contains code to parse complex configuration files. It steps through the file, reading in values for directives declared in an array of pre-defined structur- es outlining the anatomy of configuration options. It uses function pointers to allow extensibility. Rather than re-programming the function that reads and parses the file itself, you can make functions that perform sp- ecific tasks per directive. You can also perform a task for unknown directives not declared in your array. The way that this parser is written is very simple, and how complex of a set of features you want to allow in your file is dependent on the functions you have it exe- cute. It is possible to read apache style config files accura- tely, .htaccess files, and other styles. -- Devin dteske@scribe9.vicor.com figpar $ wc -l *.= h *.c 123 figpar.h 40 string_m.h 376 figpar.c 292 string_m.c 831 total I recently had to resurrect string_m.{c,h} for another project, and made th= em suitable for the FreeBSD tree: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/fdpv/ (if you're interested; really just pointing at string_m.{c,h}) I wrote figpar back in 2002 and it's pretty simple. It parses any POSIX style file and lets *you* (as the user of figpar) decid= e how different matches are handled. It indeed has what the OP was interest= ed in... Do X when you get NUM (instead of all separate types, etc.). >From figpar.h: =3D=3D=3D /* cfgvalue_t is a 4 byte union that allows you to store varied types of data in a single common container. */ typedef union { char *str; /* a pointer to a null terminated string */ int32_t num; /* a signed 32-bit integer value */ u_int32_t boolean:1; /* boolean integer value (0 or 1) */ u_int32_t u_num; /* an unsigned 32-bit integer value */ char **strarray; /* pointer to an array of strings */ } cfgvalue_t; =3D=3D=3D The OP would simply bump that union to 8 bytes and make the default "num" b= e a u_int64_t (not how there is also "u_num" etc.). The rest is pretty simple. Of the 499 lines that comprise figpar.h and figp= ar.c, there's only two typedefs to learn and two funtions to utilize. The r= est you bring to the table yourself (you add functions for handling directi= ves by "match" -- uses fnmatch(3) to match a configuration directive and fi= re your function). I've used this to parse pretty much any config file ever seen (from apache = httpd.conf to jail.conf-style configuration files). HINT: You can match on = "{" and implement a state/identifier-machine to implement groupings. What it does is remove all the nasty details of how to parse a file and let= you worry about what gets fired when it deems it's found a match to one of= your definitions. It also tries to keep things nice, as you pass it a struct-array of definit= ions (which I find helpful because I can have a nice block-definition that'= s centrally located for continuous munging). Sure, it'd need some style(9) application (I wrote it in 2002), but it's al= so extremely portable (tested successfully on over 4-dozen platforms). As you can see from the union above, it supports most types and you can ext= end it to support more. But in my experience, I've never needed more than t= hat basic set. Of course, as it is under 500 lines, it may not be as flexible as bison+yac= c, but it's never done me wrong (and pretty easy for any person on a distri= buted project to grasp and run-with). My 2 cents. -- 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. _____________ 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 Fri Jul 19 16:28:39 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B970FF8; Fri, 19 Jul 2013 16:28:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BA03A2D6; Fri, 19 Jul 2013 16:28:38 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA11557; Fri, 19 Jul 2013 19:28:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V0DXo-000A5u-FQ; Fri, 19 Jul 2013 19:28:36 +0300 Message-ID: <51E968FC.20905@FreeBSD.org> Date: Fri, 19 Jul 2013 19:27:40 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: VOP_MKDIR/VOP_CREATE and namecache X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS 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: Fri, 19 Jul 2013 16:28:39 -0000 Should VOP_MKDIR and VOP_CREATE immediately insert newly created vnodes into the namecache? If yes, where would it be done best? FS code, VFS code, VOP post-hooks, something else? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sat Jul 20 07:19:06 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7320F181; Sat, 20 Jul 2013 07:19:06 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3739A7F3; Sat, 20 Jul 2013 07:19:06 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 54D7E46C3; Sat, 20 Jul 2013 07:19:05 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id EB9F635891; Sat, 20 Jul 2013 09:19:07 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jordan Hubbard Subject: Re: General purpose library for name/value pairs. References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> Date: Sat, 20 Jul 2013 09:19:07 +0200 In-Reply-To: <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> (Jordan Hubbard's message of "Mon, 8 Jul 2013 10:57:17 -0700") Message-ID: <86y591zok4.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: 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: Sat, 20 Jul 2013 07:19:06 -0000 Jordan Hubbard writes: > That's a good idea. Since you're re-inventing Apple's XML property > list API (but without serialization and quite a few other things), He's not reinventing anything. He's implementing Solaris's nvpair API, which includes serialization - in fact, ZFS's on-disk format is based on serialized nvlists. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Jul 20 18:34:51 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E06D2792 for ; Sat, 20 Jul 2013 18:34:50 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id B820FF67 for ; Sat, 20 Jul 2013 18:34:50 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id lj1so5570328pab.31 for ; Sat, 20 Jul 2013 11:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=vJaaCvalguJPg7YRPyjkarMBFJ0pCHQAsUVVBvnKGX0=; b=YexOT7o/T30SIyNn1hwpj+Fj2whlvcn+U2qtEzZDPitpmTTyT1zIK4RYcZL8FEttw4 3A+BKSQRQfcFyldhsxAOMJyzWLkwkNxnxfvJwcAxelhaQ/qbVHMvCRO0PMPEzmhlOYk9 hcHy5MHX6oWrDUfqBdP8UNd05L5iQaaLBdCUc4nS1lWmCvMpagGm3FGfu/hDlQHmyP92 Dz5BdtMRlyji0pgs37TSiygkTO7ZYCN34m1sReAF6DxEkNgxOQFiLjIo8dllShj8gq7H iiW8rDTEixOdSCDmSR9NovY1XTiPbXatkB4AEZIkRRtZ8vxmq4YufbbfSp680ka3FAhC nvlg== X-Received: by 10.68.201.6 with SMTP id jw6mr23308238pbc.202.1374345290486; Sat, 20 Jul 2013 11:34:50 -0700 (PDT) Received: from [10.20.30.70] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id aj3sm29616379pad.8.2013.07.20.11.34.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jul 2013 11:34:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: General purpose library for name/value pairs. From: "Jordan K. Hubbard" In-Reply-To: <86y591zok4.fsf@nine.des.no> Date: Sat, 20 Jul 2013 11:34:48 -0700 Message-Id: References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <86y591zok4.fsf@nine.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1510) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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: Sat, 20 Jul 2013 18:34:51 -0000 On Jul 20, 2013, at 12:19 AM, Dag-Erling Sm=F8rgrav wrote: > He's not reinventing anything. He's implementing Solaris's nvpair = API, > which includes serialization - in fact, ZFS's on-disk format is based = on > serialized nvlists. Well, OK, perhaps "reinventing" was the wrong word, though if he's = "reimplementing" the nvlist part of Solaris's nvpairs then it sounds = like he just needs to finish the reimplementation since there's still no = serialization. Either that or start over / mutate it, since the more I = look at = http://docs.oracle.com/cd/E23824_01/html/821-1469/nvpair-name-3nvpair.html= the more I go "wow, this looks really bare-metal in its approach to, = well, everything!" I'm also not in love with Apple's Property List APIs or mechanism, = they're just what I'm familiar with and, as you and others have pointed = out, everyone and their dog seems to have gone down the same road at = some point with nvpair, libprop (NetBSD) and probably at least a few = others we're missing. I looked at libprop and it actually looks pretty = decent. - Jordan