On Wed, 16 Jul 2008 21:07:40 +0200 Goswin von Brederlow <goswin-v-b@xxxxxx> wrote: > "Jose R. Santos" <jrs@xxxxxxxxxx> writes: > > > On Wed, 16 Jul 2008 12:31:48 -0400 > > Theodore Tso <tytso@xxxxxxx> wrote: > > > >> 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. > > > > I was mostly referring to external users of the library. > > > >> 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. > > > > I agree and have already retracted my previous statement base on this. > > > >> > >> 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. > > > > While I agree that we should not put this limitation on > > ext2fs_get_device_size2(), why does EFBIG (or something equivalent when > > we implement this outside of get_size) have to means anything other > > that the size is bigger than what the current library support. It > > could be 48bit, 64bit or 1024bit, if we hit it, the current library > > will not support it. > > > > I dont see the point in having (for example) EFBIG_48 and EFBIG_64 if > > we implement EFBIG right. > > Here EFBIG means the size is bigger than what is representable in the > current datatype. Both 48bit and 64bit block counter are representable > in blk64_t. A 128bit size on the other hand would be not. As long as > the size can be represented correctly in the return type the caller > can check itself if it exceeds their own limits. > > As such the ext2fs_get_device_size() function (and all other wrappers > returning a blk_t) really should do something like this: > > blk64_t size64; > retval = ext2fs_get_device_size2(device_name, blocksize, &size64); > if (!retval && size64 >= 2^32) return EFBIG; > *size = size64; > return retval; You've exposed another bug. I obviously was not paying to much attention when doing mke2fs changes. I will fix in the next release. > > MfG > Goswin > > PS: as blk64_t can represent any size we can possibly get (ioctl, stat > and llseek methods only give 64bit) I see no reason to have an EFBIG > for now. Agree. -JRS -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
