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:17 UTC|newest]
Thread overview: 113+ 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-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.