Re: E2fsprogs 1.20 released
Yann Dirson <ydirson@altern.org> writes:
> [CCing the boot-floppies team]
>
> On Thu, Jun 07, 2001 at 08:49:54AM -0400, Theodore Tso wrote:
> > As long as they don't care about needing debugfs, they can probably
> > save 12k, maybe as much as 15k. How desperate for space are they?
12-15k is nothing to sneeze at. We really do need the space, esp with
i18n issues possibly coming in.
> > Is the boot floppy also supposed to double as a rescue floppy? If so,
> > removing debugfs might not be such a hot idea.
>
> IIRC it's the case.
Um, well, not really. You *can* use the boot/root floppies as a
rescue system, but it kinda sucks for that, and I always recommend
people use the better, specialized uni-floppy linux distributions.
>
> > The other way of doing this if they're really desparate for space
> > would be to make a new configure option, --enable-small-subset which
> > built a version of e2fsprogs that had been cut down for use on
> > installation floppies. This allows further cuts, such as not
> > supporting byte-swapping filesystems (needed to convert very old
> > Linux-PPC filesystems to the standard ext2 byte order; doing this
> > would save approximately 3k from e2fsck and libext2fs). This would
> > also not build debugfs and resize2fs, and automatically contain the
> > right list of functions that could be removed from libext2fs (as well
> > as using #ifdef to remove functions with .o files that can't be used).
> > I could remove all use of inline functions from e2fsck, which will slow
> > it down some, but make it quite a bit smaller.
> >
> > So if they're truly desparate for space, it may be possible to save a
> > some more by making much more invasive changes to e2fsprogs.
Well, Ted, I hardly want to do anything to make the source itself
harder to maintain, to change, to release, or to understand. Those
issues override our needs, IMHO.
We do have space desperation, sure, insofar as we're trying to fit
internationalized message catalogs on the damn disk not to mention the
locales messages catalogs. That last one is the "low-hanging
watermelon" we need to put our energy into, IMHO.
I just figured the pic libraries would be a pretty easy way to save
10-20k.
> > If they're in a big hurry, I'd advise doing this as a new debian
> > package with a diff file that modified lib/ext2fs/Makefile.in to
> > remove certain files, removed debugfs and resize2fs from the list of
> > directories to be built, etc.
See mumblings above about not wanting to add a maintenance burden...
> Probably it can be handled in one source package, using a modified
> version of DBS (the thing used to build X and such). I was looking
> for an excuse to make a jam-based version of DBS, cool :)
>
> > If they're going to be code slipping for another six months anyway
> > :-), I can look into making the mods into e2fsprogs in a "clean" way,
> > i.e., using configure options to control how it's built.
>
> investigating... plans for base system appear to be:
>
> - fix release-critical bugs before July 1st
> - hard freeze July 20th
It's probably too tight to attempt this ...
--
.....Adam Di Carlo....adam@onshore.com.....<URL:http://www.onshored.com/>
Reply to: