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] [day] [month] [year] [list]
Date:	Wed, 09 Aug 2006 03:18:39 -0600
From:	Hans Reiser <reiser@...esys.com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Alexander Zarochentsev <zam@...esys.com>,
	Andrew Morton <akpm@...l.org>, reiserfs-dev@...esys.com,
	linux-kernel@...r.kernel.org
Subject: Re: partial reiser4 review comments

Christoph Hellwig wrote:

> I must admit that standalone code snipplet doesn't really tell me a lot.
>
>Do you mean the possibility to pass around a filesystem-defined structure
>to multiple allocator calls?  I'm pretty sure can add that, I though it
>would be useful multiple times in the past but always found ways around
>it.
>
>  
>
Assuming I understand your discussion, I see two ways to go, one is to
pass around fs specific state and continue to call into the FS many
times, and the other is to instead provide the fs with helper functions
that accomplish readahead calculation, page allocation, etc., and let
the FS keep its state naturally without having to preserve it in some fs
defined structure.  The second approach would be cleaner code design,
that would also ease cross-os porting of filesystems, in my view.

As a philosophy of design issue, the current VFS and generic code leaves
me with the feeling that people are trying to write the FS rather than
trying to help the FS writer with some useful library functions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ