From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [PATCH 03/17] VFS: Implement handling for pathless pioctls Date: Wed, 17 Jun 2009 01:47:11 -0600 Message-ID: <20090617074711.GZ13073@webber.adilger.int> References: <20090616203845.4526.60013.stgit@warthog.procyon.org.uk> <20090616203901.4526.200.stgit@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Cc: torvalds@osdl.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, Wang Lei To: David Howells Return-path: Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:53842 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751863AbZFQHr5 (ORCPT ); Wed, 17 Jun 2009 03:47:57 -0400 Content-disposition: inline In-reply-to: <20090616203901.4526.200.stgit@warthog.procyon.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 16, 2009 21:39 +0100, David Howells wrote: > Implement handling for pathless pioctls. Because these take no path argument, > there's no way to know for certain which filesystem they're aimed at, so we > have to switch on command number instead. This patch allows interested parties > to register handlers. Each registered handler function is tried in turn until > one doesn't return -EOPNOTSUPP. > > This is required because OpenAFS implemented a number of AFS calls that don't > get given a path as they're aimed at AFS in general, and not at a particular > file, volume or cell in the AFS world. Wouldn't it make a lot more sense to create a virtual device, open the mountpoint, or do _something_ that associates these calls with AFS directly instead of having the kernel magically route the call to a specific filesystem? Not that I agree with having a filesystem-specific syscall either (sys_reiserfs() was not allowed either :-), but wouldn't even that be better suited to doing AFS-specific things? Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.