linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* How much do we care about building e2fsprogs on Solaris?
@ 2019-11-10  4:52 Theodore Y. Ts'o
  0 siblings, 0 replies; only message in thread
From: Theodore Y. Ts'o @ 2019-11-10  4:52 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: linux-ext4, harshads

Hey Darrick,

I'm thinking about reverting the following commit, which was
introduced over a decade ago for better Solaris portability.

commit 1911bf113ef0f9c71090f26279e4a4082fae0abc
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Jul 13 08:04:36 2008 -0400

    e2fsck: Change kmem_cache_t to lkmem_cache_t for Solaris

    Solaris polutes the C namespace with kmem_cache_t when
        you include in/netinet.h is included, so rename kmem_cache_t
	    to lkmem_cache_t.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

I've been working on getting e2fsck/{recovery.c,revoke.c} better
sync'ed up with the kernel versions of these files.  See the next
branch on e2fsprogs.git for my work in this area, in particular
commits 71030cf8^..46e1286a

One of the last remaining deltas is a hack to rename kmem_cache_t to
lkmem_cache_t, to work around the above described a Solaris bug.
There is a shell script, contrib/jbd2-resync.sh which we use to try to
things in sync, but it is a bit of a pain.

So this brings up two questions, which I suspect you're uniquely
qualified to answer:

(a) Does Solaris still have this namespace leakage bug in
<in/netinet.h>, such that e2fsprogs would fail to compile on Solaris
if we were to revert this commit?

(b) If Solaris still has this bug, after a over decade, do we care?
These days, Solaris doesn't seem to have much salience other than
being a program loader for a certain enterprise database, and I'm very
interested in trying to reduce the maintenance burden of keeping these
two files from fs/jbd2 in sync with the kernel, without having to put
some awful hacks on the kernel side.

					- Ted

P.S.  There are some changes that were made on the e2fsprogs side,
mostly to clean up some UBSan issues, but there's a spelling fix in a
comment and a few other miscellaneous things where the right fix is to
migrate the patch from e2fsprogs to the kernel.  Harshad is going to
work on that, in preparation for his next version of the fast commit
patches, and then getting those changes supported in e2fsprogs.

I believe I've migrated all of the improvements from the kernel's
versions of fs/jbd2/{recovery,revoke}.c to e2fsprogs, to make
Harshad's job simpler.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-11-10  4:52 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-10  4:52 How much do we care about building e2fsprogs on Solaris? Theodore Y. Ts'o

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).