From: Hans Reiser <reiser@namesys.com>
To: Vladimir Saveliev <vs@namesys.com>
Cc: Pekka Enberg <penberg@gmail.com>,
Alexander Zarochentcev <zam@namesys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
ReiserFS List <reiserfs-list@namesys.com>
Subject: Re: -mm -> 2.6.13 merge status
Date: Thu, 23 Jun 2005 10:17:21 -0700 [thread overview]
Message-ID: <42BAEEA1.2060305@namesys.com> (raw)
In-Reply-To: <1119543302.4115.141.camel@tribesman.namesys.com>
Vladimir Saveliev wrote:
>
>
>>>>+/*
>>>>+ * Initialization stages for reiser4.
>>>>+ *
>>>>+ * These enumerate various things that have to be done during reiser4
>>>>+ * startup. Initialization code (init_reiser4()) keeps track of what stage was
>>>>+ * reached, so that proper undo can be done if error occurs during
>>>>+ * initialization.
>>>>+ */
>>>>+typedef enum {
>>>>+ INIT_NONE, /* nothing is initialized yet */
>>>>+ INIT_INODECACHE, /* inode cache created */
>>>>+ INIT_CONTEXT_MGR, /* list of active contexts created */
>>>>+ INIT_ZNODES, /* znode slab created */
>>>>+ INIT_PLUGINS, /* plugins initialized */
>>>>+ INIT_PLUGIN_SET, /* psets initialized */
>>>>+ INIT_TXN, /* transaction manager initialized */
>>>>+ INIT_FAKES, /* fake inode initialized */
>>>>+ INIT_JNODES, /* jnode slab initialized */
>>>>+ INIT_EFLUSH, /* emergency flush initialized */
>>>>+ INIT_FQS, /* flush queues initialized */
>>>>+ INIT_DENTRY_FSDATA, /* dentry_fsdata slab initialized */
>>>>+ INIT_FILE_FSDATA, /* file_fsdata slab initialized */
>>>>+ INIT_D_CURSOR, /* d_cursor suport initialized */
>>>>+ INIT_FS_REGISTERED, /* reiser4 file system type registered */
>>>>+} reiser4_init_stage;
>>>>
>>>>
>>>>
>>>>
>>>Please use regular gotos instead. This is a silly hack especially since you
>>>don't have release function for all of the stages.
>>>
>>>
>>>
>>>
>>I'll let vs comment.
>>
>>
>>
>
>IMHO, it is convinient. But lets change it as requested.
>
>
No, if you like it, say so and it stays.
>>>>+ *
>>>>+ * kmalloc/kfree leak detection: reiser4_kmalloc(), reiser4_kfree(),
>>>>+ * reiser4_kfree_in_sb().
>>>>
>>>>
>>>>
>>>>
>>>Please don't do this! We've had enough trouble trying to get the
>>>current subsystem specific allocators out, so do not introduce a new one. If
>>>you need memory leak detection, make it generic and submit that. Reiser4, like
>>>all other subsystems, should use kmalloc() and friends directly.
>>>
>>>
>>>
>>>
>>I will let vs comment.
>>
>>
>>
>I agree with Pekka.
>
>
Ok, can you make it generic easily?
>
>
>>>
>>>
>>>
>>>
>>>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>>>+++ linux-2.6.11-vs/fs/reiser4/debug.h 2005-06-03 17:49:38.297184283 +0400
>>>>+
>>>>+/*
>>>>+ * Error code tracing facility. (Idea is borrowed from XFS code.)
>>>>
>>>>
>>>>
>>>>
>>>Could this be turned into a generic facility?
>>>
>>>
>>>
>
>I do not think that it will ever become accepted.
>To get use of that task_t would have to be extended with fields to store
>error code, file name and line in it, and several return addresses.
>Moreover lines like
>return -ENOENT;
>would have to be replaced with:
>return RETERR(-ENOENT);
>
>This is debugging feature, we should probably move it to our internal
>debugging patch.
>
>
>
>>>
>>>
>>>
>>>
>>>>+#define reiser4_internal
>>>>
>>>>
>>>>
>>>>
>>>Please drop the above useless #define.
>>>
>>>
>>>
>
>ok
>
>
>
>>>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>>>+++ linux-2.6.11-vs/fs/reiser4/init_super.c 2005-06-03 17:51:27.959201950 +0400
>>>>+
>>>>+#define _INIT_PARAM_LIST (struct super_block * s, reiser4_context * ctx, void * data, int silent)
>>>>+#define _DONE_PARAM_LIST (struct super_block * s)
>>>>+
>>>>+#define _INIT_(subsys) static int _init_##subsys _INIT_PARAM_LIST
>>>>+#define _DONE_(subsys) static void _done_##subsys _DONE_PARAM_LIST
>>>>
>>>>
>>>>
>>>>
>>>Please remove this macro obfuscation.
>>>
>>>
>>>
>>>
>>vs, I think he is right, do you?
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>+
>>>>+_DONE_EMPTY(exit_context)
>>>>+
>>>>+struct reiser4_subsys {
>>>>+ int (*init) _INIT_PARAM_LIST;
>>>>+ void (*done) _DONE_PARAM_LIST;
>>>>+};
>>>>+
>>>>+#define _SUBSYS(subsys) {.init = &_init_##subsys, .done = &_done_##subsys}
>>>>+static struct reiser4_subsys subsys_array[] = {
>>>>+ _SUBSYS(mount_flags_check),
>>>>+ _SUBSYS(sinfo),
>>>>+ _SUBSYS(context),
>>>>+ _SUBSYS(parse_options),
>>>>+ _SUBSYS(object_ops),
>>>>+ _SUBSYS(read_super),
>>>>+ _SUBSYS(tree0),
>>>>+ _SUBSYS(txnmgr),
>>>>+ _SUBSYS(ktxnmgrd_context),
>>>>+ _SUBSYS(ktxnmgrd),
>>>>+ _SUBSYS(entd),
>>>>+ _SUBSYS(formatted_fake),
>>>>+ _SUBSYS(disk_format),
>>>>+ _SUBSYS(sb_counters),
>>>>+ _SUBSYS(d_cursor),
>>>>+ _SUBSYS(fs_root),
>>>>+ _SUBSYS(safelink),
>>>>+ _SUBSYS(exit_context)
>>>>+};
>>>>
>>>>
>>>>
>>>>
>>>The above is overkill and silly. parse_options and read_super, for
>>>example, are _not_ a subsystem inits but regular fs ops. Please consider
>>>dropping this altogether but at least trim it down to something sane.
>>>
>>>
>>>
>
>Pekka, would you prefer something like:
>
>reiser4_fill_super()
>{
> if (init_a() == 0) {
> if (init_b() == 0) {
> if (init_c() == 0) {
> if (init_last() == 0)
> return 0;
> else {
> done_c();
> done_b();
> done_a();
> }
> } else {
> done_b();
> done_a();
> }
> } else {
> done_a();
> }
> }
>}
>
>
I think the above is easier to read than the below. Macros can obscure
sometimes, and one of our weaknesses is a tendency to use macros in such
a way that it frustrates meta-. use in emacs. Nikita did however
mention that there was something that could understand macros when
constructing tags files, but I forgot what that was.
>With these macros we have reiser4_fill_super to look like the below, and
>it remains unchanged when something new is added for initilizing on
>filesystem mounting.
>
>reiser4_fill_super()
>{
> for (i = 0; i < REISER4_NR_SUBSYS; i++) {
> ret = subsys_array[i].init(s, &ctx, data, silent);
> if (ret) {
> done_super(s, i - 1);
> return ret;
> }
> }
>}
>
>
>
>
>
>
next prev parent reply other threads:[~2005-06-23 17:29 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050620235458.5b437274.akpm@osdl.org.suse.lists.linux.kernel>
2005-06-21 11:14 ` -mm -> 2.6.13 merge status Andi Kleen
2005-06-21 18:44 ` Hans Reiser
2005-06-21 19:56 ` Andi Kleen
2005-06-21 20:21 ` Christoph Hellwig
2005-06-22 1:38 ` Hans Reiser
2005-06-22 1:57 ` Jeff Garzik
2005-06-22 1:57 ` Andi Kleen
2005-06-22 2:55 ` Hans Reiser
2005-06-22 3:01 ` Jeff Garzik
2005-06-22 8:09 ` Hans Reiser
2005-06-22 8:24 ` Jeff Garzik
2005-06-23 6:22 ` Pekka Enberg
2005-06-23 7:42 ` Hans Reiser
2005-06-23 8:08 ` Pekka J Enberg
2005-06-23 13:10 ` Hans Reiser
2005-06-23 16:15 ` Vladimir Saveliev
2005-06-23 16:23 ` Olivier Galibert
2005-06-23 19:56 ` Ross Biro
2005-06-23 17:17 ` Hans Reiser [this message]
2005-06-23 21:18 ` Nikita Danilov
2005-06-23 18:37 ` Jeff Mahoney
2005-06-23 18:43 ` Andrew Morton
2005-06-23 19:29 ` Jeff Mahoney
2005-06-23 19:45 ` Hans Reiser
2005-06-23 19:32 ` Jens Axboe
2005-06-25 16:46 ` Pekka Enberg
2005-06-25 19:23 ` Hans Reiser
2005-06-25 21:08 ` Theodore Ts'o
2005-06-26 1:03 ` Hans Reiser
2005-06-25 23:54 ` Hubert Chan
2005-06-26 10:03 ` Nikita Danilov
2005-06-27 7:24 ` Jens Axboe
2005-06-27 7:28 ` Andi Kleen
2005-06-27 7:49 ` Pekka J Enberg
2005-06-27 8:19 ` Jörn Engel
2005-06-27 8:20 ` Andi Kleen
2005-06-27 12:27 ` [PATCH] verbose BUG_ON reporting Pekka J Enberg
2005-06-27 12:38 ` Andi Kleen
2005-06-27 12:45 ` Pekka J Enberg
2005-06-27 12:40 ` [PATCH] " Jörn Engel
2005-06-23 19:24 ` -mm -> 2.6.13 merge status Hans Reiser
2005-06-24 1:13 ` Hubert Chan
2005-06-26 0:45 ` Christian Trefzer
2005-06-26 1:13 ` Hans Reiser
2005-06-26 2:23 ` Christian Trefzer
[not found] ` <42B831B4.9020603@pobox.com.suse.lists.linux.kernel>
[not found] ` <42B87318.80607@namesys.com.suse.lists.linux.kernel>
[not found] ` <20050621202448.GB30182@infradead.org.suse.lists.linux.kernel>
[not found] ` <42B8B9EE.7020002@namesys.com.suse.lists.linux.kernel>
[not found] ` <42B8BB5E.8090008@pobox.com.suse.lists.linux.kernel>
2005-06-22 1:26 ` reiser4 plugins Andi Kleen
2005-06-22 2:47 ` Hans Reiser
2005-06-22 3:16 ` Kyle Moffett
2005-06-22 15:29 ` Nikita Danilov
2005-06-23 13:20 -mm -> 2.6.13 merge status Ian Pratt
2005-06-23 13:37 ` Mark Williamson
[not found] <4hNoW-1yo-37@gated-at.bofh.it>
[not found] ` <4hT1h-5V0-41@gated-at.bofh.it>
[not found] ` <4hXHv-1br-41@gated-at.bofh.it>
2005-06-22 14:40 ` Bodo Eggert
-- strict thread matches above, loose matches on Subject: below --
2005-06-21 6:54 Andrew Morton
2005-06-21 12:01 ` Andrey Panin
2005-06-21 12:35 ` Alan Cox
2005-06-21 13:07 ` Arjan van de Ven
2005-06-22 10:50 ` Erik Slagter
2005-06-21 12:43 ` Carsten Otte
2005-06-21 12:58 ` Jörn Engel
2005-06-21 14:08 ` Martin Hicks
2005-06-21 19:54 ` Andrew Morton
2005-06-21 20:00 ` Martin Hicks
2005-06-21 15:26 ` Jeff Garzik
2005-06-21 15:39 ` Robert Love
2005-06-21 19:22 ` Christoph Lameter
2005-06-21 19:38 ` Robert Love
2005-06-21 19:44 ` Christoph Lameter
2005-06-21 20:02 ` Zan Lynx
2005-06-21 20:06 ` Christoph Lameter
2005-06-21 20:07 ` Robert Love
2005-06-21 20:10 ` Christoph Lameter
2005-06-21 20:15 ` Zan Lynx
2005-06-22 5:53 ` Matthias Urlichs
2005-06-21 22:54 ` Alan Cox
2005-06-21 20:52 ` Stephen Hemminger
2005-06-21 22:45 ` Jeff Garzik
2005-06-21 23:30 ` Christoph Lameter
2005-06-21 23:39 ` Jeff Garzik
2005-06-22 6:19 ` Christoph Lameter
2005-06-21 15:43 ` Matt Porter
2005-06-21 19:41 ` randy_dunlap
2005-06-21 20:05 ` Hans Reiser
2005-06-21 20:24 ` Christoph Hellwig
2005-06-21 20:22 ` Andrew Morton
2005-06-21 20:56 ` Gerrit Huizenga
2005-06-21 21:04 ` Andrew Morton
2005-06-21 21:23 ` Gerrit Huizenga
2005-06-21 21:38 ` Arjan van de Ven
2005-06-22 6:33 ` Martin J. Bligh
2005-06-21 21:28 ` Carsten Otte
2005-06-22 23:32 ` Chris Wright
2005-06-23 13:04 ` Carsten Otte
2005-06-22 16:53 ` Eric W. Biederman
2005-06-22 20:52 ` Andrew Morton
2005-06-23 2:14 ` Eric W. Biederman
2005-06-24 4:06 ` Paul Jackson
2005-06-24 4:54 ` randy_dunlap
2005-06-21 15:50 ` Lee Revell
2005-06-21 18:56 ` Nish Aravamudan
2005-06-22 18:00 ` Nish Aravamudan
2005-06-21 20:32 ` Andrew Morton
2005-06-21 20:37 ` Lee Revell
2005-06-22 5:51 ` Christoph Hellwig
2005-06-27 9:06 ` Christoph Hellwig
2005-06-27 14:25 ` Vladimir Saveliev
2005-06-27 19:26 ` Christoph Hellwig
2005-06-27 19:44 ` Joel Becker
2005-06-27 20:26 ` Christoph Hellwig
2005-06-27 19:30 ` Christoph Hellwig
2005-06-27 20:37 ` Hans Reiser
2005-06-30 18:30 ` Vitaly Fertman
2005-06-27 20:19 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42BAEEA1.2060305@namesys.com \
--to=reiser@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@gmail.com \
--cc=reiserfs-list@namesys.com \
--cc=vs@namesys.com \
--cc=zam@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox