To: serue@us.ibm.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] Simple tamper-proof device filesystem.
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
References: <200712232344.JBJ90661.FQOFtFOVLJHSOM@I-love.SAKURA.ne.jp>
	<20071231200247.GA30373@sergelap.austin.ibm.com>
In-Reply-To: <20071231200247.GA30373@sergelap.austin.ibm.com>
Message-Id: <200801011116.AFH73928.MHFLtOSOOVJFQF@I-love.SAKURA.ne.jp>
Date: Tue, 1 Jan 2008 11:16:55 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1162
Lines: 29

Hello.

Thank you for reviewing.

Serge E. Hallyn wrote:
> > This time, I'm implementing this filesystem as an extension to tmpfs
> > because what this filesystem does are nothing but check filename and
> > its attributes in addition to what tmpfs does.
> 
> To integrate this nicer into tmpfs, at least define TMPFS_IS_MAC as 1
> and TMPFS_NOT_MAC as 0 and pass those values instead of just 1 and 0.
> 
Question to everybody:
  Not all users need this extension, so I'm worrying that integrating
  this extension into tmpfs increases memory usage needlessly.
  May I implement this filesystem as an extension to tmpfs
  provided that users can enable/disable this extension via kernel config?

> Again, I should think you'd actually want to take blkdev_open() from
> fs/block_dev.c and chrdev_open() from fs/char_dev.c.  Surely your
> method of grabbing it here is not acceptable for upstream code.
I see.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/