include/linux/efs_fs.h declares a symbol

Hi!

Al, your version string cprt[] should better be in one of the .c files and the declaration in the header be extern. No need to keep six seperate copies of that string in the kernel binary.

Thanks!

Al Viro: There is no maintainer for efs in the kernel MAINTAINERS file. Is this filesystem orphaned?

Jörn

But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

Sure, absolutely.

My answer would be yes and no. Yes, I'd like to keep it up to date with the kernel in general, but in terms of actual development it's been in a stable state for a couple of years now, and I have no current plans to add further features.

Beats me. As far as I can see, all updates to it were 3rd-party. It's either abandoned, or never required specific patches too badly (also quite possible in this case).

It went into the tree in 2.3.2 and from there to 2.6.0-test6 I see nothing that would look like maintainer's update. OTOH, it's read-only and shouldn't be too badly broken (or hard to keep alive).

Outside of trunk (i.e. in 2.4.16--) we have a backport of global 2.5 change (sb_bread()) and check for set_blocksize() failures (from Alan). BTW, the latter patch is missing in 2.5. Its equivalent would be

@@ -218,7 +218,11 @@
 	memset(sb, 0, sizeof(struct efs_sb_info));
  
 	s->s_magic		= EFS_SUPER_MAGIC;
-	sb_set_blocksize(s, EFS_BLOCKSIZE);
+	if (!sb_set_blocksize(s, EFS_BLOCKSIZE)) {
+		printk(KERN_ERR "EFS: device does not support %d byte blocks\n",
+			EFS_BLOCKSIZE);
+		goto out_no_fs_ul;
+	}
   
 	/* read the vh (volume header) block */
 	bh = sb_bread(s, 0);