linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/2] add cotnfigure option --with-root-libdir
Date: Wed, 29 Aug 2018 19:51:41 -0400	[thread overview]
Message-ID: <20180829235141.GL19128@thunk.org> (raw)
In-Reply-To: <20180829210455.GA77879@jaegeuk-macbookpro.roam.corp.google.com>

On Wed, Aug 29, 2018 at 02:04:55PM -0700, Jaegeuk Kim wrote:
> Thank you so much for kind explanation. This is really awesome especially for
> newbies like me. This gives answers to me for all my own stupid questions like
> why I need to investigate all the lib changes in order to determine bumping
> current/revision/age numbers or not.
> 
> I'd definitely like to follow this rule to avoid any verion changes later, as
> I expect the next release will be the last major update. For dependency parts,
> I'll study and practice them for a while.

If you are going to be making one less major update, this is the
perfect time to make sure that data structures are allocated by the
library, and are (ideally) opaque to the calling application (so they
only manipulate structure poitners).  That is, the structure
definition is not exposed in the public header file, and you use
accessor functions to set and get fields in the structure.

If you can't do that for all data structures, if you can do that with
your primary data structure that's going to make your life much easier
in the long term.  For ext2fs, that's the file systme handle.  It's
created by ext2fs_open(), and it's passed to all other library
functions as the first argument.

The other thing you might want to consider doing is adding a magic
number to the beginning of each structure.  That way you can tell if
the wrong structure gets passed to a library.  It's also helpful for
doing the equivalent of subclassing in C.

This is how we do it in libext2fs --- we use com_err to define the
magic numbers:

	error_table ext2

ec	EXT2_ET_BASE,
	"EXT2FS Library version @E2FSPROGS_VERSION@"

ec	EXT2_ET_MAGIC_EXT2FS_FILSYS,
	"Wrong magic number for ext2_filsys structure"

ec	EXT2_ET_MAGIC_BADBLOCKS_LIST,
	"Wrong magic number for badblocks_list structure"
	...

And then every single structure starts like so:

struct struct_ext2_filsys {
	errcode_t			magic;
	...

struct ext2_struct_inode_scan {
	errcode_t		magic;
	...

And then before we use any pointer we do this:

	if (file->magic != EXT2_ET_MAGIC_EXT2_FILE)
		return EXT2_ET_MAGIC_EXT2_FILE;

Anyway, you don't have to do any of this, but if you're thinking about
making a big major version number bump, this is a great opportunity to
do some of these things.

> BTW, can I archive this like in f2fs-tools/VERSIONING?

Sure, feel free!

					- Ted

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

  reply	other threads:[~2018-08-30  4:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-20  3:04 [PATCH 1/2] add configure option --with-root-libdir Theodore Ts'o
2018-08-20  3:04 ` [PATCH 2/2] Ask git to ignore the generated sg_write_buffer executable Theodore Ts'o
2018-08-20  7:21   ` Chao Yu
2018-08-27 15:51 ` [PATCH 1/2] add configure option --with-root-libdir Theodore Y. Ts'o
2018-08-27 16:57   ` Jaegeuk Kim
2018-08-27 23:56     ` Theodore Y. Ts'o
2018-08-28  7:12       ` Jaegeuk Kim
2018-08-28 14:25         ` Theodore Y. Ts'o
2018-08-28 16:59           ` Jaegeuk Kim
2018-08-29  3:10             ` [PATCH 1/2] add cotnfigure " Theodore Y. Ts'o
2018-08-29 21:04               ` Jaegeuk Kim
2018-08-29 23:51                 ` Theodore Y. Ts'o [this message]
2018-08-28  3:43 ` [PATCH 1/2] add configure " Chao Yu

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=20180829235141.GL19128@thunk.org \
    --to=tytso@mit.edu \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    /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 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).