Bryn M. Reeves wrote: > -----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).
The library is very low level. Actually my experience with the e2fsprogs thing is a little bit unexpected. All the magic happens somewhere else different from the library calls. Of course I didn't know that some weeks ago. :/ >>> >>> 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. > I agree with this. It will inevitable be duplicating the logic. However, I'll try to finish the project as a proof of concept, to see how exactly the library would fit into the code and then decide if its worth presenting.... > 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----- -- Joel Andres Granados Red Hat / Brno, Czech Republic _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
