Minimal configuration for e2fsprogs

On Fri, Jun 15, 2012 at 08:08:25PM -0400, Ted Ts'o wrote:

> So I think you need to break your list a bit more.  There are a number
> of functions on this list where, if yaboot doesn't actually call a
> particular function (for example, the progess bar functions, in
> lib/ext2fs/progress.c), the fact that they reference the stdio
> functions won't matter.  Something similar will be going on with
> test_io.c; if you don't use those functions, you won't need to provide
> stubs for any of the libc functions called by them.

I'm not certain we're on the same page.  We're linking statically so
that fact we don't call the progress functions doesn't matter.  The
code is in libext2fs.a and there must be a call path from (eg)
ext2fs_open() to fwrite(stderr, ...).  The fact we don't add the 
EXT2_FLAG_PRINT_PROGRESS doesn't come into it does it?

What have I misunderstood?

> There are some cases where we may need to create some configure
> options.  For example, there are a large number of the symbols that
> you have listed that got dragged in by the lib/ext2fs/mmp.c.  That's
> one where it may be simplest to add a set of #ifdef's that comment out
> multi-mount protection --- I assume you don't plan to support booting
> over fibre channel where you might need to care about having two
> systems trying to modify the same file system at the same time.  :-)

No we really don't need mmp :)  I can see creating --enable-mmp and
--disbale-mmp options for configure would be reasonable and not too
intrusive, and it gets rid of nearly 30% of the libc functions.

Something like this lightly tested patch:
---
---

Feedback very welcome but if it looks okay I'll add my signed off and
resubmit with a reasonable commit message.

> Which brings up another point --- are you only planning on opening the
> file system read-only, or do you expect to modify the file system from
> yaboot?  If you don't need to modify the file system, and so you don't
> need to load the bitmap manipulation functions, that will make a whole
> bunch more of the libc dependencies drop out.

Well currently we open it read-write but I cannot see a problem with
switching to read-only.  Based on my very limited understanding of
e2fsprogs it seems that disabling the bitmap functions is good for yaboot
it would result in a library that has pretty limited value to anyone
else.

A really ugly local hack to disbale the bitmap functions (along with the
patch above) results in calloc() being the only missing symbol.  Adding
calloc is probably a good idea anyway :)

> So the bottom line is yes, I think we can do somethings to help you;
> but depending on which parts of the libext2fs functionality yaboot
> actually needs, it may not be as bad as you think, especially if you
> are willing to limit which libext2fs functions you call.

We're a very simple user.  We only support ext* on local disks so no
fibre channel or anything too fancy.

For the record we currently only call:
	ext2fs_open()
	ext2fs_namei_follow()
	ext2fs_follow_link()
	ext2fs_read_inode()
	ext2fs_close()
	ext2fs_block_iterate()
	ext2fs_bmap() # Actually we may not use this anymore 

I'm also happy to rewrite the yaboot code for ext* if someone with
more knowledge can make a provide pointers.

I'd like to keep the headaches involved with using yaboot "small", so if
I can do a little extra work now to ensure that users not need to really
care what options (dir_index etc) the file-system is created with I'm
all for that.

Yours Tony

Minimal configuration for e2fsprogs

Commit Message

Comments

Patch