Re: adding fdisk GPT support

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

 



On 05/12/2009 02:28 PM, Karel Zak wrote:
  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.
Kernel is where i started. But using the kernel code seemed rather difficult to start with, not only because kernel only does reading/parsing, also because some things are simply done differently there. Of course, whether it'd be more work to use kernel code rather than try to cleanup fdisk code, that is a question.
  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.
Refactoring is necessary either way, whether as a start of a "ptread" library, or to be able to make it work with a similar library from different source.
  (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.)
If they're not willing to split libparted into PT handling lib and FS handling lib, I totally share the opinion of its [non]usefulness for simple tools like fdisk. And after seeing the parted code, I don't think such a split would be easilly done, let alone the probable lack of motivation to do it. I believe parted simply has its own solid place in the tool hierarchy, definitely different one than that of fdisk.
  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.
I'll go and check more of them. The kernel code may give a good overview as it contains probably the most complete label set support.
  BTW, the number of your regression tests for fdisk(s) is ZERO :-(
..which is directly proportional to the difficulty of writing any tests for this mess. ;) I'll try to think of a way to throw in some tests. A quick and simple idea: make *fdisk operate on file streams instead of block devices, and create a large set of prepared MBR's for blackbox testing (perform an operation, and check the result against the expected result using a shell script). A big problem is faking all the ioctl stuff (?). Unit tests should definitely be employed ONLY after the code has at least some decent layout and API settled, if they're not to be rewritten all the time.


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

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux