Re: [PATCH] ext4: move headers out of include/linux

On Sun, Feb 10, 2008 at 07:54:32AM -0500, Theodore Tso wrote:

No, none of this is shared with e2fsprogs; e2fsprogs stopped using the
kernel header files about seven years ago. (May 2001, e2fsprogs 1.20).

Yeah, I know userspace stopped using the direct copy.  But for example
XFS has exact copies of some headers under fs/xfs also in the userspace
package.  But I assume your answer means you have a completely separate
set of headers for e2fsprogs, which makes sense given it supports ext2,
ext3 and ext4 all with one codebase.

quoted

quoted

Note that I plan to submit similar patches for ext2 and ext3 aswell,
so the diverging from them argument doesn't count.

There might be other programs like grub that may depend upon ext2_fs.h
or ext3_fs.h....  <apt-get source / grep>   Nope, not grub.  So a few
things might break, but they are all programs that should have been
using the libraries shipped with e2fsprogs, and they wouldn't be 
critical programs.  So no problems that I know of.

We might have to leave the user-space visible parts of ext2_fs.h
in place due to historical reasons, so I will leave that part out of
the first patch.  I don't think that argument is valid for ext3_fs.h
as ext3 only go into mainline at the same time as /usr/include/ext2fs/
started appearing even if ext3_fs.h is exported currently.

Note Linus just accepted a pull from me (although it just missed the
-git21 snapshot window --- <aside> it would be nice if that happend at
3am Pacific instead of midnight Pacific since very occasionally it's a
little after midnight before Linus pushes his last set of changes to
master.kernel.org</aside>) so this patch won't apply cleanly to the
Linus's tip.  I'll take the patch DTRT so it can be placed in the ext4
tree.

Updated patch is in the same location:
	
	http://verein.lst.de/~hch/ext4-move-headers

Also, on the git list, Linus mentioned the -rc1 merge window would be
closing soon, though, so I don't know if this will make 2.6.25.  If it
doesn't, would you mind terribly if we put this on hold and *not* have
this in the -mm tree until right before the next merge window opens.
It's mostly a mechnical change, doesn't need much testing --- and it
complicates patch management which I know has been making Andrew a bit
grumpy as of late.

Yeah, if it's too late already we can defer it.