From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 13 12:08:10 2013 Return-Path: Delivered-To: freebsd-hackers@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 97C236B7; Thu, 13 Jun 2013 12:08:10 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABEC1977; Thu, 13 Jun 2013 12:08:09 +0000 (UTC) Received: from dsl-tkubrasgw1-54fa22-153.dhcp.inet.fi (84.250.34.153) by jenni1.inet.fi (8.5.140.03) id 5163EC560460B28D; Thu, 13 Jun 2013 15:06:53 +0300 Date: Thu, 13 Jun 2013 15:06:54 +0300 From: Jaakko Heinonen To: Hans Petter Selasky Subject: Re: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail? Message-ID: <20130613120653.GA1467@dsl-tkubrasgw1-54fa22-153.dhcp.inet.fi> References: <20130509110718.0000528e@unknown> <518C060E.8040301@gmail.com> <20130510121133.00001e2a@unknown> <518CDD73.9090405@uffe.org> <20130510213303.00005078@unknown> <51B9650D.1050601@bitfrost.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B9650D.1050601@bitfrost.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: usb@freebsd.org, Alexander Leidinger , Uffe Jakobsen , avg@FreeBSD.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:08:10 -0000 On 2013-06-13, Hans Petter Selasky wrote: > Can we introduce a new syntax while keeping the old behaviour? > > path zvol/* hide-r > path zvol/* unhide-r > > I think this will be more accepted than changing existing behaviour! IMHO, the old behavior is so confusing and unintuitive that we should not maintain it. Can you clarify how "hide-r" and "unhide-r" would differ from plain "hide" and "unhide". The current syntax already uses pattern matching via fnmatch(9). > Is this stack element really needed? > > + char specname[SPECNAMELEN + 1]; Need to check if M_WAITOK malloc is possible here. -- Jaakko