All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Smith <patsmith@pobox.com>
To: reiserfs-list@namesys.com
Subject: Re: reiserfsck on PPC: checkmem fails
Date: Wed, 05 Feb 2003 01:17:28 -0500	[thread overview]
Message-ID: <3E40AC78.9050907@pobox.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

> I'm using ReiserFS on a PowerPC.  The filesystem works fine in normal 
> use, but I'm having a bit of trouble with reiserfsck.
> 
> Versions:  reiserfsprogs 3.6.4, Linux kernel 2.4.20.

After looking into this a bit more, I've become quite confused and worried.

Various places in the code, arrays of bits are maintained.  Two 
different approaches seem to be taken:

ext2_test_bit, ext2_set_bit, etc. group bits into 8-bit bytes.  The 
kernel's bitmap.c uses this approach (but not everywhere).

test_bit, set_bit, etc. group bits into 32-bit words (at least in the 
PPC version).  The kernel's journal.c uses this approach.  As far as I 
can tell, only this approach is used in reiserfsprogs.

On a little-endian machine, the two approaches should be equivalent, so 
the distinction wouldn't matter much.

On a big-endian machine such as PPC, they are quite different, so each 
piece of data should be accessed with only one of the two approaches. 
But as far as I can tell, the kernel's bitmap.c accesses the block 
bitmaps with the first approach, and reiserfsprogs' bitmap.c uses the 
second approach.  :-(

On the other hand, when I tried modifying the reiserfsprogs bitmap.c to 
group bits by bytes instead of words, reiserfsck --check spewed a 
zillion error messages.  So maybe I've got something wrong above.

In any case, might I suggest standardizing on one of the two approaches 
throughout?  Preferably the byte-wise approach, for the sake of portability.

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1140 bytes --]

--- ./include/misc.h.orig	2002-09-13 06:09:28.000000000 -0400
+++ ./include/misc.h	2002-12-24 22:31:08.000000000 -0500
@@ -49,7 +49,10 @@
 int uuid_is_correct (unsigned char * uuid);
 int set_uuid (const unsigned char * text, unsigned char * UUID);
 
+#include <asm/byteorder.h>
+#define __KERNEL__
 #include <asm/bitops.h>
+#undef __KERNEL__
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 int le_set_bit (int nr, void * addr);
 int le_clear_bit (int nr, void * addr);
--- ./include/io.h.orig	2002-09-01 11:32:07.000000000 -0400
+++ ./include/io.h	2002-12-24 22:31:08.000000000 -0500
@@ -2,6 +2,7 @@
  * Copyright 1996-2002 Hans Reiser
  */
 
+#include "misc.h"
 
 struct buffer_head {
     unsigned long b_blocknr;
--- ./include/swab.h.orig	2002-08-07 05:12:07.000000000 -0400
+++ ./include/swab.h	2002-12-24 22:32:09.000000000 -0500
@@ -4,5 +4,15 @@
 #ifndef _REISERFS_SWAB_H_
 #define _REISERFS_SWAB_H_
 
+#include <asm/byteorder.h>
+#define __KERNEL__
+#include <asm/bitops.h>
+#undef __KERNEL__
+
 #include <linux/byteorder/swab.h>
+
+#define swab16 __swab16
+#define swab32 __swab32
+#define swab64 __swab64
+
 #endif /* _REISERFS_SWAB_H_ */


             reply	other threads:[~2003-02-05  6:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-05  6:17 Patrick Smith [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-06  3:58 reiserfsck on PPC: checkmem fails Patrick Smith
2003-02-08 12:59 ` Vitaly Fertman
2003-02-04  5:44 Patrick Smith

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=3E40AC78.9050907@pobox.com \
    --to=patsmith@pobox.com \
    --cc=reiserfs-list@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.