Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Dec 2002 09:52:28 -0500 (EST)
From:      Somil Asthana <asthana@cse.Buffalo.EDU>
To:        <freebsd-questions@FreeBSD.ORG>
Subject:   Stackable File System 
Message-ID:  <Pine.SOL.4.30.0212240951280.4933-100000@pollux.cse.buffalo.edu>

next in thread | raw e-mail | index | archive | help
Hi All:
  I am trying to develop a simple encrypted stackable file system.
Instead of making a new stackable file system I modified nullfs code
itself. I added null_read() and null_write() functions. null_read()
internally calls VOP_READ() and null_write() calls VOP_WRITE() (it bypass
control to lower vnode vectors VOPS). The code of null_write() function is
such that before calling VOP_WRITE() it increments each character pointed
by uio_iov->iov_base[i] by 1 and null_read() does the opposite ie it
decrement each character pointed by uio_iov->iov_base[i] by 1 after
calling VOP_READ. So for example if I open a file and store "ABCDE" it
actually gets stored as "BCDEF" but when I read it back using cat
program or read system call I get "BCDEF" not "ABCDE".I can see the code
is going to null_read() and uio_iov->iov_base[i] is actually printing
"ABCDE" on console. Whats surprising is that user space cat or read system
call are not giving the correct output or I should say that modified uio
structure is not reflected in user space.

I am mounting using this command

 sudo mount -t null /mnt/ /TMP/

 So in /TMP dir has a nullfs is on top of ufs

Am I missing something here ? I can see that the control is actually going
to null_read and null_write and I have tested that nullfs is on top of ufs
in /TMP directory.

thank you
Somil





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.4.30.0212240951280.4933-100000>