On Tue, May 12, 2009 at 03:27:49PM +0200, Zdenek Behan wrote:
> On 05/12/2009 11:36 AM, Karel Zak wrote:
>> 1) write "libptread" library
>>
> [...]
>> 2) write "libptwrite" library (with functionality like
>>
> A library abstraction of PT handling code should definitely be the
> ultimate goal. It is also the goal for me. The thing which I see
> differently is: the code for the possible future library
> (ptread/ptwrite) already exists in fdisk, only is in a horrible
The code in fdisk is a small subset. In the ptread library we have to
support all possible labels -- this is not so difficult, because the
code already exists in Linux kernel (see fs/partitions/ directory),
partx(8) and libparted.
This is reason why I'd like to start with ptread rather than with
fdisk refactoring -- write ptread is relatively simple task. But I
don't have a strong opinion about it -- you can start with fdisk
refactoring of course. I'll be happy with arbitrary useful patch.
> unmaintainable shape. I'd like to take the refactoring/cleanup steps
> first, and after fdisk has its label handling nice and clean like a baby
> butt, it is rather trivial to take it and abstract that one more step
> into a library and make fdisk&others use it.
>
> Do you think there's a more suitable base code from which the work
> should be started? From the *fdisk stuff, I believe the fdisk (not
> [sc]fdisk) code is the most mature and maintained one from my
> inspection. I didn't check other utilities that do partition table
> handling.
(Note that GNU Parted is again actively maintained. For example Jim
Meyering is working on parted now. But I have my doubts that we will
ever see libparted as a library that is useful for basic system
utils.)
The ideal solution is review all available PT parsers (at least the
code in Linux kernel, fdisk(s), partx and libparted). I expect some
differences and I don't believe there is an "ideal" implementation.
>>> 3) Error reporting/handling
>>>
> I nearly forgot. It is not only error checking/handling. One of the
> major problems is that the label-specific functions often do direct
> interaction with the user, ie. read input and produce output in general.
> That is unacceptable (even for monolithic code), and needs to be slowly
> moved up in the hierarchy towards the main fdisk utility code, rather
> than label-specific code.
Yes.
>> I think fdisk code could be refactored in parallel to work on the
>> libs. But don't forget to use small easy-to-review patches.
>>
> ... as usually. ;) There'll be basically two phases. a) Taking fdisk,
> cutting it into several pieces of code, and basically moving most
> functions out into separate files where they should've always been. That
> is going to be a _HUGE_ patch, with almost no real code changes, just
> moving things around, and it's quite pointless to split that into
> smaller pieces. b) Taking the resulting code, and refactoring it piece
> by piece towards the ultimate goal - clean separation of abstract
> library-like code and UI. That should be several small patches, each
> having its own specific purpose.
Yes.
BTW, the number of your regression tests for fdisk(s) is ZERO :-(
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
