From owner-freebsd-usb@FreeBSD.ORG  Thu Jun 13 12:08:10 2013
Return-Path: <owner-freebsd-usb@FreeBSD.ORG>
Delivered-To: usb@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 <jh@FreeBSD.org>
To: Hans Petter Selasky <hps@bitfrost.no>
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, avg@FreeBSD.org, freebsd-hackers@freebsd.org
X-BeenThere: freebsd-usb@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: FreeBSD support for USB <freebsd-usb.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-usb>,
 <mailto:freebsd-usb-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-usb>
List-Post: <mailto:freebsd-usb@freebsd.org>
List-Help: <mailto:freebsd-usb-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-usb>,
 <mailto:freebsd-usb-request@freebsd.org?subject=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