From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 23 06:10:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 839F3106566B for ; Fri, 23 Apr 2010 06:10:48 +0000 (UTC) (envelope-from czerner.lukas@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 07B0C8FC08 for ; Fri, 23 Apr 2010 06:10:47 +0000 (UTC) Received: by bwz27 with SMTP id 27so496720bwz.13 for ; Thu, 22 Apr 2010 23:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-x-sender:to:cc :subject:in-reply-to:message-id:references:user-agent:mime-version :content-type; bh=eoRfvAeLizQgZ7ublNE46R06KM7a7J7l/G9/8YTqJGg=; b=j7jZ7vDB6iuDslKMud01qwWE0wouiLYm1nNovp9M8CVao/PCEgIWrHgFA1wZNRZE5V GIIPwBK6a/NQBoGB08op7HxIaKFHYEKw1jJxqa1w2FFRIj3hz6I9OKwIq7zmi1bSIQmo HcB2Qdauvgxl8bgKm/JjbWkYPMOgmeCY4M+ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=I9NMpDizbttL9k2Xlr/vPMLDBkisZPZbLr30EMB9HwJ+NhDuzVm4F1TVBbPj9TANnS RfLTWREACvdvUntRv5jKwnKYQCiP8miwlIgjqNtgqZizJXU7nGWvZx85pSlykLlqi3kp QSb9/4rIH775x51G8St6xz4lq7rOdbIgRAmMU= Received: by 10.102.165.11 with SMTP id n11mr6023742mue.23.1272003046510; Thu, 22 Apr 2010 23:10:46 -0700 (PDT) Received: from a04-0215a.kn.vutbr.cz (a04-0215a.kn.vutbr.cz [147.229.216.20]) by mx.google.com with ESMTPS id z10sm389854fka.1.2010.04.22.23.10.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Apr 2010 23:10:45 -0700 (PDT) Date: Fri, 23 Apr 2010 08:10:44 +0200 (CEST) From: "=?ISO-8859-15?Q?Luk=E1=A8_Czerner?=" X-X-Sender: bratt@a04-0215a.kn.vutbr.cz To: Gleb Kurtsou In-Reply-To: <20100422191849.GA9895@tops> Message-ID: References: <20100422191849.GA9895@tops> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-123159715-1272003045=:7101" Cc: freebsd-hackers@freebsd.org, =?ISO-8859-15?Q?Luk=E1=A8_Czerner?= Subject: Re: How to change vnode operations ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 06:10:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-123159715-1272003045=:7101 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT On Thu, 22 Apr 2010, Gleb Kurtsou wrote: > Date: Thu, 22 Apr 2010 22:18:49 +0300 > From: Gleb Kurtsou > To: Lukáš Czerner > Cc: freebsd-hackers@freebsd.org > Subject: Re: How to change vnode operations ? > > On (22/04/2010 16:02), Lukáš Czerner wrote: > > Hi all, > > > > this may sound a little odd, since I have noticed that there is much > > work done to not allow such a thing ($SUBJ). But may be you can help > > me and point me to the right direction. > > > > I am writing a kernel module with somewhat similar functionality > > like nullfs has, BUT it has to have some features which nullfs > > itself does not provide : > > > > 1. I need the new layer to completely hide underlaying layer so no > > one can bypass it. > Is hypothetic 'mount -t mynullfs /a /a' good enough for you? I'm not sure > what your goals are but completely finding underlaying filesystem won't > be easy because of VFS_GET, getfh and other stuff operating with inode > numbers. Well, it may be good enough, or not. Thats what I am trying to find out. Obviously there are problems, as you mentioned, which will not exist when I change the vop_vector of the vnode, but as I thought and you mentioned it as well, this is not very clean way. > > > 2. Nullfs allows me to to overlay just one directory, but i want to > > include another directories and/or exclude subdirectories/files. > > 3. Nullfs just redirects vnode operations to lower layer, I need to > > catch that operation, do something (for example alter the arguments > > somehow etc..), pass the operation (with possibly altered arguments) > > to the lower layer, get the result and then return the result. > I'd suggest to take a look at pefs: http://github.com/glk/pefs > It's cryptographic stacked filesystem for FreeBSD. It changes file > names, hides directory entries, modifies data from lower layer > (encrypts or decrypts), supports mounting on same directory, etc. Thats great, thanks! I will look at it. > > > The best way to do that (I think) is to change vnode operations of > > particular vnodes to point to functions defined in that module. At > > this point, I can catch any operations with the vnode and this is > > the base of what i want. > > > > So my question is. I there any "clean" way to chande vnode > > operations ? If not, is there any "not so clean" way ? Anyway I will > > appreciate any good idea how to do what I have described. > Imho, stacked filesystem is the only right way to do it (see null, > unionfs, pefs). OK. Thanks for pointing me to the pefs, it is interesting and looks like a good start. But I would appreciate more comment on the side of the whole idea about changing vnode operations from the kernel module. It is a little hacky, but aside this I do not see any bigger problems, do you ? Thanks. -Lukas --8323329-123159715-1272003045=:7101--