From owner-svn-src-all@FreeBSD.ORG Wed Apr 14 15:42:53 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4216B1065670; Wed, 14 Apr 2010 15:42:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AED4F8FC12; Wed, 14 Apr 2010 15:42:52 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o3EFgmco040831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Apr 2010 18:42:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o3EFgmqD000803; Wed, 14 Apr 2010 18:42:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o3EFgmqA000802; Wed, 14 Apr 2010 18:42:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Apr 2010 18:42:48 +0300 From: Kostik Belousov To: Jaakko Heinonen Message-ID: <20100414154248.GR2415@deviant.kiev.zoral.com.ua> References: <201004131853.o3DIrdOT035078@svn.freebsd.org> <20100414084037.GK2415@deviant.kiev.zoral.com.ua> <20100414124912.GA2950@a91-153-117-195.elisa-laajakaista.fi> <20100414130343.GO2415@deviant.kiev.zoral.com.ua> <20100414141959.GA3276@a91-153-117-195.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2fP9eRwxR5lvdkO" Content-Disposition: inline In-Reply-To: <20100414141959.GA3276@a91-153-117-195.elisa-laajakaista.fi> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r206560 - head/sys/fs/devfs X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 15:42:53 -0000 --a2fP9eRwxR5lvdkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2010 at 05:20:00PM +0300, Jaakko Heinonen wrote: > On 2010-04-14, Kostik Belousov wrote: > > > Otherwise sounds reasonable suggestion. However changes are needed in > > > devfs. Currently devfs_populate_loop() is not along the make_dev*() > > > code path but make_dev(9) increases a generation counter and > > > devfs_populate_loop() gets called sometimes later. To make things more > > > complex there may be several devfs mounts with different symlinks (fi= les). > > Right, my point of my suggestion was to not modify populate_loop() at a= ll. >=20 > How you would detect an attempt to create a duplicate file then? Please > note that there may be directories and user created symbolic links. The > file set may be different on different devfs mounts. First, I think we shall sort dirent->dd_dlist so that symlinks are located before any other entries, and allow for duplication of any name with the name of symlink. I remember there was a PR to change devfs_symlink() so that symlink is added to dd_dlist into head, not to a tail, as it is done now. The change itself is not enough, but together with other parts of this it might be ok. Assume that all full devfs pathes except symlinks are stored somewhere with type information for the component at the end. Then, just iterating this set at make_dev() time, we can verify that name is not a duplicate, and that the path components are not already used as device name (only as directories). The pathes storage need to be protected by dev_mtx.=20 Possibly, the cdev_priv.c_dev.__si_namebuf may be reused at the cost of long check at the make_dev() time. The symlink creation shall also put the path of its containing directory into the store. What do you think of this ? --a2fP9eRwxR5lvdkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvF4ncACgkQC3+MBN1Mb4j3BQCfWYVWBBAd+a+QAtgdSQ7u6Be7 NcoAn0geNdMZXjY5ETj7UheQCBm48/CZ =BOJe -----END PGP SIGNATURE----- --a2fP9eRwxR5lvdkO--