[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: E2fsprogs 1.20 released



[CCing the boot-floppies team]

On Thu, Jun 07, 2001 at 08:49:54AM -0400, Theodore Tso wrote:
> On Thu, Jun 07, 2001 at 10:24:54AM +0200, Yann Dirson wrote:
> > 
> > FWIW, I've added support for pic libraries to the elf-lib Makefile, on
> > request of the boot-floopies guys, and was waiting for their feedback to
> > forward it to you (quite trivial addition, and without interactions with
> > the other things anyway).  I'm still curious to see if they'll manage to
> > reduce the shared libs size with this - in case you don't know, it's an
> > ar archive build with the same .o files as the shared lib, used to build
> > a stripped-down shared lib with only the needed parts for the tools in
> > the boot-floppies.  My guess is that mke2fs and e2fsck use most of the
> > shared libs anyway, so size reduction would not be so great - do you
> > confirm ?
> 
> 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?
> 
> 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.

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

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

-- 
Yann Dirson    <ydirson@altern.org> |    Why make M$-Bill richer & richer ?
debian-email:   <dirson@debian.org> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>



Reply to: