Linux-ext4 Archive on
 help / color / Atom feed
From: "Theodore Y. Ts'o" <>
To: "Darrick J. Wong" <>
Subject: How much do we care about building e2fsprogs on Solaris?
Date: Sat, 9 Nov 2019 23:52:06 -0500
Message-ID: <> (raw)

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 <>
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" <>

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

                 reply index

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ext4 Archive on

Archives are clonable:
	git clone --mirror linux-ext4/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-ext4 linux-ext4/ \
	public-inbox-index linux-ext4

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone