Date: Thu, 22 Jan 2004 08:28:41 +0000 From: Colin Percival <colin.percival@wadham.ox.ac.uk> To: Mike Makonnen <mtm@identd.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/devfs devfs_rule.c Message-ID: <6.0.1.1.1.20040122082056.04321990@imap.sfu.ca> In-Reply-To: <20040122074937.GB1013@mobile.acsolutions.com> References: <200401211643.i0LGhT43093728@repoman.freebsd.org> <20040122074937.GB1013@mobile.acsolutions.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:49 22/01/2004, Mike Makonnen wrote: >On Wed, Jan 21, 2004 at 08:43:29AM -0800, Colin Percival wrote: > > Allow devfs path rules to work on directories. Without this fix, > > devfs rule add path fd unhide > > is a no-op, while it should unhide the fd subdirectory. > >Does this affect /etc/defaults/devfs.rules? No, but we might want to change devfs.rules. >I am assuming that the 'add hide' in the first ruleset will now also >hide /dev/fd (where it previously didn't). The 'add hide' was always hiding /dev/fd. It just wasn't possible to unhide it without unhiding everything. (devfs_rule_matchpath is only called if the rule specifies a path; prior to this fix, it would always return "no, this doesn't match" when applied to a directory.) >In that case will the >'add path fd/* unhide' in a later rule unhide the fd/ directory? Does >it need a separate 'add fd unhide'? Given that 'add path fd/* unhide' currently unhides entries within a hidden directory, it would probably makes sense to add a separate 'add path fd unhide'. :) Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.1.1.1.20040122082056.04321990>