mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vladimir Saveliev <vs@namesys.com>
To: Pekka Enberg <penberg@gmail.com>
Cc: 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 20:15:03 +0400	[thread overview]
Message-ID: <1119543302.4115.141.camel@tribesman.namesys.com> (raw)
In-Reply-To: <42BA67C9.7060604@namesys.com>

Hello

On Thu, 2005-06-23 at 11:42, Hans Reiser wrote:
> Pekka Enberg wrote:
> 
> >
> >>--- /dev/null	2003-09-23 21:59:22.000000000 +0400
> >>+++ linux-2.6.11-vs/fs/reiser4/pool.c	2005-06-03 17:49:38.668204642 +0400
> >>+/* initialise new pool */
> >>+reiser4_internal void
> >>+reiser4_init_pool(reiser4_pool * pool /* pool to initialise */ ,
> >>+		  size_t obj_size /* size of objects in @pool */ ,
> >>+		  int num_of_objs /* number of preallocated objects */ ,
> >>+		  char *data /* area for preallocated objects */ )
> >>+{
> >>+	reiser4_pool_header *h;
> >>+	int i;
> >>+
> >>+	assert("nikita-955", pool != NULL);
> >>    
> >>
> >
> >These assertion codes are meaningless to the rest of us so please drop
> >them.
> > 

Pekka, am I correct that you object aginst assertion ids like "joe-700"?

> >>--- /dev/null	2003-09-23 21:59:22.000000000 +0400
> >>+++ linux-2.6.11-vs/fs/reiser4/type_safe_hash.h	2005-06-03 17:49:38.751209197 +0400
> >>@@ -0,0 +1,320 @@
> >>+/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by
> >>+ * reiser4/README */
> >>+
> >>+/* A hash table class that uses hash chains (singly-linked) and is
> >>+   parametrized to provide type safety.  */
> >
> >This belongs to include/linux, not reiser4.

ok.

> >>--- /dev/null	2003-09-23 21:59:22.000000000 +0400
> >>+++ linux-2.6.11-vs/fs/reiser4/type_safe_list.h	2005-06-03 17:49:38.755209417 +0400
> >>@@ -0,0 +1,436 @@
> >>+/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by reiser4/README */
> >>+
> >>+#ifndef __REISER4_TYPE_SAFE_LIST_H__
> >>+#define __REISER4_TYPE_SAFE_LIST_H__
> >>+
> >>+#include "debug.h"
> >>+/* A circular doubly linked list that differs from the previous
> >>+   <linux/list.h> implementation because it is parametrized to provide
> >>+   type safety.  This data structure is also useful as a queue or stack.
> >
> >This belongs to include/linux, not reiser4.
> >

ok

> >>+/*
> >>+ * 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.

> >  
> >
> >>+reiser4_internal void reiser4_handle_error(void)
> >>+{
> >>+	struct super_block *sb = reiser4_get_current_sb();
> >>+
> >>+	if ( !sb )
> >>+		return;
> >>+	reiser4_status_write(REISER4_STATUS_DAMAGED, 0, "Filesystem error occured");
> >>+	switch ( get_super_private(sb)->onerror ) {
> >>+	case 0:
> >>+		reiser4_panic("foobar-42", "Filesystem error occured\n");
> >>+	case 1:
> >>+		if ( sb->s_flags & MS_RDONLY )
> >>+			return;
> >>+		sb->s_flags |= MS_RDONLY;
> >>+		break;
> >>+	case 2:
> >>+		machine_restart(NULL);
> >>    
> >>
> >
> >Probably not something you should do at fs level.
> >  
ok

> >>+
> >>+	/* not yet phash_jnode_destroy(ZJNODE(node)); */
> >>+
> >>+	/* poison memory. */
> >>+	ON_DEBUG(memset(node, 0xde, sizeof *node));
> >>    
> >>
> >
> >Poisoning belongs to slab, not fs.
> >  

ok

> >  
> >
> >>+/* allocate fresh znode */
> >>+reiser4_internal znode *
> >>+zalloc(int gfp_flag /* allocation flag */ )
> >>+{
> >>+	znode *node;
> >>+
> >>+	node = kmem_cache_alloc(znode_slab, gfp_flag);
> >>+	return node;
> >>+}
> >>    
> >>
> >
> >Please drop this useless wrapper.
> >  

ok

> >  
> >
> >>+reiser4_internal void
> >>+znode_remove(znode * node /* znode to remove */ , reiser4_tree * tree)
> >>+{
> >>+	assert("nikita-2108", node != NULL);
> >>+	assert("nikita-470", node->c_count == 0);
> >>+	assert("zam-879", rw_tree_is_write_locked(tree));
> >>+
> >>+	/* remove reference to this znode from cbk cache */
> >>+	cbk_cache_invalidate(node, tree);
> >>+
> >>+	/* update c_count of parent */
> >>+	if (znode_parent(node) != NULL) {
> >>+		assert("nikita-472", znode_parent(node)->c_count > 0);
> >>+		/* father, onto your hands I forward my spirit... */
> >>+		znode_parent(node)->c_count --;
> >>+		node->in_parent.node = NULL;
> >>+	} else {
> >>+		/* orphaned znode?! Root? */
> >>    
> >>
> >
> >Drop the useless else branch.
> >  
> >
> >>--- /dev/null	2003-09-23 21:59:22.000000000 +0400
> >>+++ linux-2.6.11-vs/fs/reiser4/debug.c	2005-06-03 17:49:38.293184063 +0400
> >>@@ -0,0 +1,447 @@
> >>+/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by
> >>+ * reiser4/README */
> >>+
> >>+/* Debugging facilities. */
> >>+
> >>+/*
> >>+ * This file contains generic debugging functions used by reiser4. Roughly
> >>+ * following:
> >>+ *
> >>+ *     panicking: reiser4_do_panic(), reiser4_print_prefix().
> >>+ *
> >>+ *     locking: schedulable(), lock_counters(), print_lock_counters(),
> >>+ *     no_counters_are_held(), commit_check_locks()
> >>+ *
> >>+ *     {debug,trace,log}_flags: reiser4_are_all_debugged(),
> >>+ *     reiser4_is_debugged(), get_current_trace_flags(),
> >>+ *     get_current_log_flags().
> >>+ *
> >>+ *     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.

> >  
> >
> >>--- /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();
	}
    }
}

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;
		}
	}
}



  parent reply	other threads:[~2005-06-23 16:16 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 ` 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 [this message]
2005-06-23 16:23               ` Olivier Galibert
2005-06-23 19:56                 ` Ross Biro
2005-06-23 17:17               ` Hans Reiser
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=1119543302.4115.141.camel@tribesman.namesys.com \
    --to=vs@namesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@gmail.com \
    --cc=reiserfs-list@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

Powered by JetHome