-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Meyering wrote: > "Bryn M. Reeves" <[EMAIL PROTECTED]> wrote: >> Joel Andres Granados wrote: >>> Jim Meyering wrote: >>>> Hi Joel, >>>> >>>> Thanks for the patch. >>>> Deprecating ext3 support is a good first step. >>> yep, its all good. My idea is not to take it away completely though. The >>> more I think about this issue the more I realize why it was put there in >>> the first place. >>> Reasons that I think we should support ext3: >>> 1. There is a library, makes things easier and makes stuff less prone to >>> bugs. >> Which library do you mean here? The last time I looked the library >> interfaces provided by e2fsprogs were themselves quite low-level. E.g. >> resize2fs is implemented on top of libext2fs but all the smarts for the >> resize operation are implemented in resize2fs itself (apart from online >> which relies more on kernel support). >> >> I think it is unwise to reinvent this kind of low-level file system >> manipulation code - if there's no direct library interface available I >> would prefer to wrap the executables rather than implement it in parted >> (or anywhere for that matter) and repeat the mistakes of >> libparted/fs/ext2/ext2_resize.c. > > Thanks for writing all that. > That was exactly my impression when I looked into making > parted use e2fsprogs library code. I certainly did not > want to duplicate all of that logic in parted.
It would be really great if each *fs project would implement a programmatic interface to its tools that had some semblance of a standardised interface. This is also something I was thinking of while designing fsadm - that we could start off with a generic exec wrapper that could interface to any set of file system specific tools (providing e.g. format specifiers and expect-style output parsers to ease parameter passing/response parsing) but eventually move towards a state where we'd hash out a uniform interface that file system implementors could conform to in order to have their tools easily plug into the fsadm framework (e.g. e2fsprogs might supply a fsadm-e2fsprogs.so, or something). That would all depend on getting sufficient buy-in for the "grand unified storage tool" concept to actually get a critical mass of file systems on board but it's something I could see beeing very useful. And of course, we still need to decide if/where we want to implement file system stuff in the first place... Cheers, Bryn. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIgNRR6YSQoMYUY94RAm89AKDAOdoEEy7DIzJF6bjSBQQN2abtqgCcC9qt Br4jgJoyo6MTUAQxq8CvvXU= =VMxm -----END PGP SIGNATURE----- _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
