linux-ext4 - Re: [PATCH 1/2] Add stack I/O manager.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 May 2007 23:31:00 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2] Add stack I/O manager.

On Wed, May 09, 2007 at 01:42:17PM +0530, Aneesh Kumar K.V wrote:
> From: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
> 
> This I/O manager helps in stacking different I/O managers.
> For example one can stack the undo I/O manager on top
> of Unix I/O manager to achieve the undo functionality.

This is probably more generality than is strictly necessary; and the
place where the excess generality gets messy is the fact that you make
the stacking layer responsible for calling all of the io manager's
open routines (which is still a FIXME).  So I would flush the stack_io
layer entirely.

What I would recommend as the fast and dirty approach.  Basically, ape
the approach used by test_io layer _exactly_, except instead of using
a global variable test_io_backing_manager, you provide a function
which sets the static variable, undo_io_backing_manager.  This
variable is used only by the subsequent call to the ->open method,
which just like test_io simply passes the name down to the backing
manager specified in the static variable.  Then just make the undo_io
manager work the way test_io does, where does its thing, and then it
calls the appropriate function in its private->real io_channel.
Basically, make undo_io responsible for calling the next io_manager
down in the chain, This is workable because we don't need to
initialize the tdb file until we first try to write to the io_channel,
and ext2fs_open() only needs to do read operations, so we can set the
tdb filename via an optoin after ext2fs_open() returns.

I could imagine a more complicated approach where we still wouldn't
have a stacking layer, but have an integrated parsing layer which
would have registered names for each of the io_managers.  It would
then take the part of the name before the colon, and treat it as the
type (i.e., "file"), and the part after the colon and pass it to the
relevant's io_manager (i.e., "/dev/sda4").  So you could pass in a
name like "file:/dev/sda4".   

For the test_io manager, since it doesn't need any arguments, it could
just take the part after the colon, and use it to pass back to the
parsing layer.  So names to test_io manager would look like this:
"test:file:/dev/sda4".

For managers that need two names, we would have to do something a bit
more complicated, like this: "undo:/var/undo/tdbfile#file:/dev/sda4".
But basically, we still make the stacking up to the individual
io_manager.  The main advantage with this approach is that all of the
stacking is done via the ASCII string provided by the user, and
there's no need for any special ad-hoc options.

On the other hand, arguably, you want the program decided where to put
the undo file, so that it can be found automatically by e2fsck.  So
the fast-and-dirty approach might be the better one anyway --- it
certainly is easier!

Regards,

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html