From owner-svn-src-all@FreeBSD.ORG Thu Apr 15 13:02:03 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 0D8861065672; Thu, 15 Apr 2010 13:02:03 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id BB6028FC19; Thu, 15 Apr 2010 13:02:01 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 524AD1518AD; Thu, 15 Apr 2010 16:01:56 +0300 (EEST) Date: Thu, 15 Apr 2010 16:01:56 +0300 From: Jaakko Heinonen To: Kostik Belousov Message-ID: <20100415130155.GA3017@a91-153-117-195.elisa-laajakaista.fi> 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> <20100414154248.GR2415@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100414154248.GR2415@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Thu, 15 Apr 2010 13:02:03 -0000 On 2010-04-14, Kostik Belousov wrote: > 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. What will happen when user deletes a symlink covering a device? Uncovering the device may a bit surprising? If user created directories will be allowed one day, they will face the same problem. > 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. kern/114057 > 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. > > Possibly, the cdev_priv.c_dev.__si_namebuf may be reused at the > cost of long check at the make_dev() time. Could you elaborate on this? I am not sure if I understand what you mean with __si_namebuf reuse. > What do you think of this ? I don't see anything obviously wrong with it. -- Jaakko