From owner-freebsd-arch@FreeBSD.ORG Mon May 7 20:26:51 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CDCB106564A; Mon, 7 May 2012 20:26:51 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB188FC0A; Mon, 7 May 2012 20:26:51 +0000 (UTC) Received: from orion.swifttest.com (unknown [74.3.97.52]) by mx0.deglitch.com (Postfix) with ESMTPA id 2142C8FC27; Tue, 8 May 2012 00:26:50 +0400 (MSK) Received: from orion.swifttest.com (localhost [127.0.0.1]) by orion.swifttest.com (Postfix) with SMTP id 16D175C98; Mon, 7 May 2012 13:23:26 -0700 (PDT) Date: Mon, 7 May 2012 13:23:25 -0700 From: Stanislav Sedov To: Baptiste Daroussin Message-Id: <20120507132325.c4bfae2d.stas@FreeBSD.org> In-Reply-To: <20120502114115.GG31034@azathoth.lan> References: <20120502114115.GG31034@azathoth.lan> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: Switching /etc/*.db from bdb to tinycdb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:26:51 -0000 On Wed, 2 May 2012 13:41:15 +0200 Baptiste Daroussin mentioned: > Hi, > > I plan to work on switching all the /etc/*.db files from bdb 1.85 to cdb (using > the tinycdb implementation) > > Reason for doing that: > 1/ we use the *.db files as a constant database on recreating them using > *_mkdb(8) commands > 2/ bdb 1.85 database are endianness dependant which can cause problem if I want > pkgng to be able to create users when cross installing packages (like adding > packages in a mips eb chroot environment on an amd64 host) > 3/ the tinycdb API is clean and easy to use (I find it easier and cleaner to > deal with it) > 4/ tinycdb is public domain so not problem for us to use it. > > On the side effects, I'm not sure this is relevant but tinycdb is also faster to > read then bdb 1.85. > > How do I plan to do it. > > I plan to import the read part or tinycdb into libc and the write part into > libutil (to avoid cluttering libc). > > Why importing to libc? to allow all the get*ent to parse the /etc/*.db files. > > How to implment it? slowly with backward compatibility: > for each kind of files: try to open with cdb, if fail fall back to bdb. > > I plan to rewrite all the *_mkdb for make them use cdb. > > Link for tinycdb: > http://www.corpit.ru/mjt/tinycdb.html > > Any opinion, ideas, advices on this? Did you look at leveldb [1], btw? It seems to be very fast, better supported, and support some advanced features that can be useful for other base applications (like transactions, custom sorting, snapshots). It's distributed under BSD license. [1] http://code.google.com/p/leveldb/ -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-arch@FreeBSD.ORG Mon May 7 20:39:33 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6C441065674; Mon, 7 May 2012 20:39:33 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6598FC14; Mon, 7 May 2012 20:39:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q47KdXAC012082; Mon, 7 May 2012 20:39:33 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q47KdXa1012081; Mon, 7 May 2012 20:39:33 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Mon, 7 May 2012 22:39:29 +0200 From: Baptiste Daroussin To: Stanislav Sedov Message-ID: <20120507203929.GS17325@azathoth.lan> References: <20120502114115.GG31034@azathoth.lan> <20120507132325.c4bfae2d.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bGopQmzlzQgFk3Fg" Content-Disposition: inline In-Reply-To: <20120507132325.c4bfae2d.stas@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org Subject: Re: Switching /etc/*.db from bdb to tinycdb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:39:33 -0000 --bGopQmzlzQgFk3Fg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 07, 2012 at 01:23:25PM -0700, Stanislav Sedov wrote: > On Wed, 2 May 2012 13:41:15 +0200 > Baptiste Daroussin mentioned: >=20 > >=20 > > Any opinion, ideas, advices on this? >=20 > Did you look at leveldb [1], btw? It seems to be very fast, better suppo= rted, and > support some advanced features that can be useful for other base applicat= ions > (like transactions, custom sorting, snapshots). >=20 > It's distributed under BSD license. >=20 > [1] http://code.google.com/p/leveldb/ >=20 Yes I had a look, and it doesn't fit imho: 1/ leveldb is c++ while for all our get*ent functions are in libc and needs= to acees the db files. 2/ leveldb is really huge compare to tinycdb. Btw: an unexpected gain of cdb is that for services for example the size of= the db is greatly reduces from 2M to 800K here, doesn't matter much but it is c= ool :) regards, Bapt --bGopQmzlzQgFk3Fg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+oMwEACgkQ8kTtMUmk6Ew5QwCfXbRKLZRpLBYsrY4wicBz1ACg EIkAn3T5RC8HJLO/XwwPFH35h4e19XiP =1MaB -----END PGP SIGNATURE----- --bGopQmzlzQgFk3Fg-- From owner-freebsd-arch@FreeBSD.ORG Mon May 7 20:48:55 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9666F106566C for ; Mon, 7 May 2012 20:48:55 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 09EBA8FC0A for ; Mon, 7 May 2012 20:48:54 +0000 (UTC) Received: by yhgm50 with SMTP id m50so5506142yhg.13 for ; Mon, 07 May 2012 13:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4jC95xvR4DdO2m2wDm4xsXujzCJ7TQmcdVepQ0/gX2A=; b=KbQ90JNBteLpPgFuxyr/ZwYN50yCC2F5FK06/C6JNKqNZrw9TE8fgYGrDv2R676u+d nCHXkmVeYeFQAA5Hr9zN5MG1HOwXeVEiPNbv2LKfNO94nfGrMpVtF3N46niTlVzDszPY 3v+v+PYVxiW6i9C62RQGbRd3gajMZATZTZUDU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4jC95xvR4DdO2m2wDm4xsXujzCJ7TQmcdVepQ0/gX2A=; b=ENPknVSgv0smmTbYG08BStqUfmV4dqmaLwJ+wIZYVnwO1rWdm9yEcyhRzNcK7LF5Wi yl/wXGjdEiccXQoFcczoJqIvJFhbIKQElhO6zGb41inpm0e25SrOq2TyVyaHubGAAgW3 PKnVd0eGKWd6SW2HQ5eXOFvtofH0Um84kKvBmZF9TTVZM3JjXu50Cn6ZG8IvAwBztDN4 yQnN+5GuhDQ392puwQsOYvHuayO0FH4fQJVmsmeecUGc7XVK50YLInw5L+O0v3r6sZeI yVxZkVLQgztE0TM3yY//GwX+qvloNOTAOl1rcwC03V/6SmIl69sn+zGjRFKQ0vXhB0CJ sBrg== MIME-Version: 1.0 Received: by 10.50.179.38 with SMTP id dd6mr9418758igc.9.1336423734217; Mon, 07 May 2012 13:48:54 -0700 (PDT) Received: by 10.231.243.4 with HTTP; Mon, 7 May 2012 13:48:54 -0700 (PDT) In-Reply-To: <20120502114115.GG31034@azathoth.lan> References: <20120502114115.GG31034@azathoth.lan> Date: Mon, 7 May 2012 13:48:54 -0700 Message-ID: From: Peter Wemm To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmsg3Poik+620yQ590wXd5Q5CjPZ16s5rHDLWybxwhT1JE0VDb71nDDFgB5leu93nccaxz3 Cc: freebsd-arch@freebsd.org Subject: Re: Switching /etc/*.db from bdb to tinycdb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:48:55 -0000 On Wed, May 2, 2012 at 4:41 AM, Baptiste Daroussin wrote: > Hi, > > I plan to work on switching all the /etc/*.db files from bdb 1.85 to cdb (using > the tinycdb implementation) > > Reason for doing that: > 1/ we use the *.db files as a constant database on recreating them using > *_mkdb(8) commands > 2/ bdb 1.85 database are endianness dependant which can cause problem if I want > pkgng to be able to create users when cross installing packages (like adding > packages in a mips eb chroot environment on an amd64 host) > 3/ the tinycdb API is clean and easy to use (I find it easier and cleaner to > deal with it) > 4/ tinycdb is public domain so not problem for us to use it. > > On the side effects, I'm not sure this is relevant but tinycdb is also faster to > read then bdb 1.85. > > How do I plan to do it. > > I plan to import the read part or tinycdb into libc and the write part into > libutil (to avoid cluttering libc). > > Why importing to libc? to allow all the get*ent to parse the /etc/*.db files. > > How to implment it? slowly with backward compatibility: > for each kind of files: try to open with cdb, if fail fall back to bdb. > > I plan to rewrite all the *_mkdb for make them use cdb. > > Link for tinycdb: > http://www.corpit.ru/mjt/tinycdb.html > > Any opinion, ideas, advices on this? Please keep in mind that old binaries need to keep working. Old libc doesn't have a text file parser in it - the only thing it knows is how to read the *.db files, so they can never go away or be made incompatible. eg: there are people "supposedly" running a libc.so.4 based oracle. Even FreeBSD-2.1.5 a.out binaries still understand the *.db files that we use (assuming you dig up the a.out stuff to make them run). Please keep backwards compatability in mind. Even if that means moving db/* to a standalone shim/converter utility or have some other way to generate/update the "old" *.db files. This has far bigger impact than things like the utmp/utx change. Also keep in mind the symbol scope stuff may not necessarily have the same visibility goals as everyything else. eg: libc.so.7 based binaries from an old machine should still "see" the new implementation - things like getpwnam() ABI won't be changing. You *do want* an ancient libc.so.7 binary that was compiled on 7.0-release to correctly use the new implementation when its run on a 10.0 machine. Please take a lot of care with a change like this. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu May 10 22:18:21 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3B4F106566B for ; Thu, 10 May 2012 22:18:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id D969A8FC0C for ; Thu, 10 May 2012 22:18:20 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 8C0E9115B4; Thu, 10 May 2012 15:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1336688300; bh=eAPiNMVOPiYP6dtteD7R+mgTqeCo+0UkR+os+aK4KgA=; h=Date:From:Reply-To:To:CC:Subject; b=zIqhMGnslx4ik6EIiOHEQEv5NIZnKz9sQa7gibvOH6343j28F2K7mbSddIoNoO1e4 rjguMvoWeWTsff5TVKCfiToxaTddvpvtpyeXbEhBS5AiAc0k2nO7qq2Dt0cvGMSdLs Qp3X3aZhBWR4LuRfLMDRRwWSH/lYouGBKMzRAjEM= Message-ID: <4FAC3EAB.6050303@delphij.net> Date: Thu, 10 May 2012 15:18:19 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: d@delphij.net Subject: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 22:18:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I've recently read some documents saying that some other operating systems would allow a small amount of memory be mlock()'ed by unprivileged process. This feature is useful for applications that needs the semantics, e.g. when requesting for memory that holds sensitive information like private keys, etc. The current implementation of ours would just return EPERM when caller is not the superuser, and enforce a limit for privileged processes (which is set to infinity). Is there any concern of changing this to allow a few memory pages be locked and remove the limit when the calling process is superuser? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPrD6rAAoJEG80Jeu8UPuzrlwIAK0e8eLvyGJgVz5E0W3Zuv+B MnDkk33VuC8qCtHCu1a3glvFMmcmgu3firfT1cDPKOEK8wxUOcWFMNd6tkB+pMA0 2K0K2xa0VG8/dr7pbhG3yASE4A5PYMvTkLLs94Q35/BC0+mvck3lv5TZWU5mDOyg OvynzLUT+QXPyteOPlkhYaF24O/ZrjA8xTXp+wV4pW4tJVCDrTJfohVsagIe3gpe douPykCdO3hlWe46ovUvJ426+i0DETC/NSa0sDmYY8FksGVkovuEQD+V+t2fm40h HyGtKRMZ95wUOea4ro35AfPzuYjkPT3JZDiWsEIMkXj4M6kADsvX/wKd24Bq1XE= =FHpe -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Fri May 11 07:08:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FCAC106566C for ; Fri, 11 May 2012 07:08:10 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel05.rubas-s05.net (cpanel05.rubas-s05.net [195.182.222.75]) by mx1.freebsd.org (Postfix) with ESMTP id F35358FC17 for ; Fri, 11 May 2012 07:08:09 +0000 (UTC) Received: from 175-3.192-178.cust.bluewin.ch ([178.192.3.175] helo=gahrfit.gahr.ch) by cpanel05.rubas-s05.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SSjPo-0001Lo-MF; Fri, 11 May 2012 08:33:24 +0200 Date: Fri, 11 May 2012 08:33:23 +0200 From: Pietro Cerutti To: d@delphij.net Message-ID: <20120511063322.GA1333@gahrfit.gahr.ch> References: <4FAC3EAB.6050303@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <4FAC3EAB.6050303@delphij.net> X-PGP-Key: 0x9571F78E X-PGP-Fingerprint: 1203 92B5 3919 AF84 9B97 28D6 C0C2 6A98 9571 F78E User-Agent: Mutt/1.5.21 (2010-09-15) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel05.rubas-s05.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arch@freebsd.org Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gahr@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 07:08:10 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-10, 15:18, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi, >=20 > I've recently read some documents saying that some other operating > systems would allow a small amount of memory be mlock()'ed by > unprivileged process. This feature is useful for applications that > needs the semantics, e.g. when requesting for memory that holds > sensitive information like private keys, etc. >=20 > The current implementation of ours would just return EPERM when caller > is not the superuser, and enforce a limit for privileged processes > (which is set to infinity). >=20 > Is there any concern of changing this to allow a few memory pages be > locked and remove the limit when the calling process is superuser? I'm all for this! --=20 Pietro Cerutti The FreeBSD Project gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp --wac7ysb48OaltWcw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk+ssrAACgkQwMJqmJVx947tXACcD/nYKnwww09EPuld4Q5W80Wb NO0An1Y8iGbHgoCgEqzr4ZyDUcxYGPeK =auX9 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-arch@FreeBSD.ORG Fri May 11 07:27:34 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7753106566B for ; Fri, 11 May 2012 07:27:34 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6C33D8FC08 for ; Fri, 11 May 2012 07:27:34 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2278495wgb.31 for ; Fri, 11 May 2012 00:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0GR8OeSNOSyipAwf2TaIP9lGtcxIDNM+VRGnNYYWUrA=; b=AAq94bRvsG/PcsAlVLi0CWF6qpNiGy/mEpigspDc3VD+U3QyHPDUp1MyBnIpRt/ypP Is48sL20t1XtrnjSSjIoHZoa28qMeW7BQVA05Cb8XcwmCRA93tT6JBKaPzVZxVNXpFPv 3sJxu2NLJg1NWgn1WUUrmsPE7Hyfcr2/5Er0mf/0QdhbrtzGAt3wQUyuqh1/9I1f7we5 68vcdCfcX6NyyLdVfZ8tCbLZyTIBM3tPd+c0EJhfGodvi83lq7hkvIvAnjR3sp60wh02 C7L0l7PZ+eEU5M91VNhaIwjhQJlZcM7x7uzhF+ix0IhVFhqn1PqspQcTtt2TucCtD2lt aIlw== MIME-Version: 1.0 Received: by 10.180.105.194 with SMTP id go2mr4815552wib.22.1336721253430; Fri, 11 May 2012 00:27:33 -0700 (PDT) Received: by 10.194.6.5 with HTTP; Fri, 11 May 2012 00:27:33 -0700 (PDT) Date: Fri, 11 May 2012 15:27:33 +0800 Message-ID: From: Howard Su To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Inotify IN_CLOSE_WRITE Support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 07:27:34 -0000 I tried inotifywait based on libinoitfy in the port. I noticed that the most interesting event to me, IN_CLOSE_WRITE, doesn't get triggered. I'd like to spend some to hack to get this supported. but I don't know where is good start point. IN_CLOSE_WRITE File opened for writing was closed (*). Anyone can give me some advice on this? -- -Howard From owner-freebsd-arch@FreeBSD.ORG Fri May 11 07:54:09 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA47B1065670 for ; Fri, 11 May 2012 07:54:09 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel05.rubas-s05.net (cpanel05.rubas-s05.net [195.182.222.75]) by mx1.freebsd.org (Postfix) with ESMTP id 57CC08FC0A for ; Fri, 11 May 2012 07:54:09 +0000 (UTC) Received: from 175-3.192-178.cust.bluewin.ch ([178.192.3.175] helo=gahrfit.gahr.ch) by cpanel05.rubas-s05.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SSkfw-000715-3l; Fri, 11 May 2012 09:54:08 +0200 Date: Fri, 11 May 2012 09:54:06 +0200 From: Pietro Cerutti To: d@delphij.net Message-ID: <20120511075406.GC1333@gahrfit.gahr.ch> References: <4FAC3EAB.6050303@delphij.net> <20120511063322.GA1333@gahrfit.gahr.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <20120511063322.GA1333@gahrfit.gahr.ch> X-PGP-Key: 0x9571F78E X-PGP-Fingerprint: 1203 92B5 3919 AF84 9B97 28D6 C0C2 6A98 9571 F78E User-Agent: Mutt/1.5.21 (2010-09-15) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel05.rubas-s05.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arch@freebsd.org Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gahr@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 07:54:09 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-11, 08:33, Pietro Cerutti wrote: > On 2012-May-10, 15:18, Xin Li wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > >=20 > > Hi, > >=20 > > I've recently read some documents saying that some other operating > > systems would allow a small amount of memory be mlock()'ed by > > unprivileged process. This feature is useful for applications that > > needs the semantics, e.g. when requesting for memory that holds > > sensitive information like private keys, etc. > >=20 > > The current implementation of ours would just return EPERM when caller > > is not the superuser, and enforce a limit for privileged processes > > (which is set to infinity). > >=20 > > Is there any concern of changing this to allow a few memory pages be > > locked and remove the limit when the calling process is superuser? >=20 > I'm all for this! + possibly limiting the number of pages per user, =C3=A0 la maxprocperuid. --=20 Pietro Cerutti The FreeBSD Project gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk+sxZ0ACgkQwMJqmJVx945fsQCfXsaNiUW9oHiB91uCMbMrOnlG nyYAoLxSqe+ump7oIZQbk6JHw99iQPq9 =qzjy -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o--