All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Jose R. Santos" <jrs@us.ibm.com>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup
Date: Wed, 16 Jul 2008 12:31:48 -0400	[thread overview]
Message-ID: <20080716163148.GC2167@mit.edu> (raw)
In-Reply-To: <20080716101817.4d40a2f9@ichigo>

On Wed, Jul 16, 2008 at 10:18:17AM -0500, Jose R. Santos wrote:
> > It's really important when doing library design to think about future
> > expandability.
> 
> This would not be a API or ABI change so I don't see why another
> renaming function would be needed.  It also doesn't change the
> behavior of ext2fs_get_device_size2() since it returns EFBIG when a
> device is larger than what e2fsprogs currently supports, whether that
> 48bit or 64bits.  Putting the limit ext2fs_get_device_size2() avoid
> folks from abusing something that probably isn't supported. 

E2fsprogs utilities are somewhat entitled to assume that they will be
running with a version of libext2fs which is the same as the one that
they shipped with --- although sometimes that assumption can be false,
particularly when people are building a newer version of e2fsprogs
from source and forget to install the newer libraries or forget to set
LD_LIBRARY_PATH if they are building with dynamic libraries.

However there may be other users of that interface, and they won't
know if version of that library they are calling is set to return
EFBIG on a 48bit or 64bit number.  Besides, there may be other
application users of that function where it would be useful to get the
size of a device which is larger than 48-bits, even if mke2fs and ext4
today doesn't support it.  This is just good library design not to
enforce limits like this in a fairly generic function.

Finally, in many programming discplines you *do* rename the function
whenever you make major semantic changes to the function, not just for
API or ABI changes.  Otherwise a newer program might depend on
ext2fs_get_device_size() returning a 64-bit size, and then it might
get very confused or fail in unexpected ways if it is linked with an
older library that returns EFBIG if the number is bigger than 48 bits.

It's just a matter of how defensive you want to be in your
programming, and how general-purpose you want you library routines to
be.

Regards,

						- Ted

  reply	other threads:[~2008-07-16 16:31 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-15 16:50 [PATCH 00/15][e2fsprogs] Initial blk64_t capable API calls Jose R. Santos
2008-07-15 16:50 ` [PATCH 01/15][e2fsprogs] libext2fs: Add 64-bit support to the undo manager Jose R. Santos
2008-07-16 11:16   ` Goswin von Brederlow
2008-07-16 13:26     ` Theodore Tso
2008-07-15 16:50 ` [PATCH 02/15][e2fsprogs] Add ext2_off64_t type Jose R. Santos
2008-07-15 16:50 ` [PATCH 03/15][e2fsprogs] Add new blk64_t handling functions Jose R. Santos
2008-07-15 16:50 ` [PATCH 04/15][e2fsprogs] Use blk64_t for blocks in struct ext2_file Jose R. Santos
2008-07-15 16:50 ` [PATCH 05/15][e2fsprogs] Add 64-bit dirblock interface Jose R. Santos
2008-07-15 16:50 ` [PATCH 06/15][e2fsprogs] Add 64-bit alloc_stats interface Jose R. Santos
2008-07-15 16:50 ` [PATCH 07/15][e2fsprogs] Add 64-bit alloc interface Jose R. Santos
2008-07-15 16:50 ` [PATCH 08/15][e2fsprogs] Add 64-bit ext_attr interface Jose R. Santos
2008-07-15 16:50 ` [PATCH 09/15][e2fsprogs] Add 64-bit closefs interface Jose R. Santos
2008-07-15 16:51 ` [PATCH 10/15][e2fsprogs] Use new ext2fs_super_and_bgd_loc2 call in libext2fs Jose R. Santos
2008-07-15 16:51 ` [PATCH 11/15][e2fsprogs] Add 64-bit openfs interface Jose R. Santos
2008-07-15 16:51 ` [PATCH 12/15][e2fsprogs] Add ext2fs_div64_ceil() Jose R. Santos
2008-07-15 16:51 ` [PATCH 13/15][e2fsprogs] Add 64-bit getsize interface Jose R. Santos
2008-07-15 16:51 ` [PATCH 14/15][e2fsprogs] Add 64-bit mkjournal.c interface Jose R. Santos
2008-07-15 16:51 ` [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup Jose R. Santos
2008-07-16 12:50   ` Goswin von Brederlow
2008-07-16 13:52     ` Goswin von Brederlow
2008-07-16 14:18       ` Jose R. Santos
2008-07-16 15:23         ` Goswin von Brederlow
2008-07-16 16:02           ` Jose R. Santos
2008-07-16 17:18             ` Theodore Tso
2008-07-16 18:03               ` Jose R. Santos
2008-07-16 18:58             ` Goswin von Brederlow
2008-07-16 14:09     ` Jose R. Santos
2008-07-16 14:54       ` Theodore Tso
2008-07-16 15:18         ` Jose R. Santos
2008-07-16 16:31           ` Theodore Tso [this message]
2008-07-16 17:26             ` Jose R. Santos
2008-07-16 19:07               ` Goswin von Brederlow
2008-07-16 19:40                 ` Jose R. Santos
2008-07-16 15:21       ` Goswin von Brederlow
2008-07-16 15:30         ` Jose R. Santos
2008-07-16 15:13   ` Goswin von Brederlow
2008-07-16 17:44     ` Jose R. Santos
2008-07-16 16:31   ` Goswin von Brederlow
2008-07-17 20:46   ` [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup [NEW Version] Jose R. Santos
2008-07-18 11:35     ` Goswin von Brederlow
2008-07-18 15:15       ` Jose R. Santos
2008-07-18 19:59         ` Goswin von Brederlow
2008-07-21  5:04           ` Andreas Dilger
  -- strict thread matches above, loose matches on Subject: below --
2008-08-20 17:32 [PATCH 00/15] [e2fsprogs] Initial blk64_t capable API calls Jose R. Santos
2008-08-20 17:34 ` [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup Jose R. Santos

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=20080716163148.GC2167@mit.edu \
    --to=tytso@mit.edu \
    --cc=goswin-v-b@web.de \
    --cc=jrs@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.