On Thu, Jan 22, 2004 at 04:18:10PM +0100, Szakacsits Szabolcs wrote: > > On Thu, 22 Jan 2004, Sven Luther wrote: > > On Wed, Jan 21, 2004 at 10:43:33PM +0100, Szakacsits Szabolcs wrote: > > > It isn't only about just moving the code to libntfs (I answered this some > > > month ago on bug-parted) but > > > > Yep, but it is the necessary step to have do the libparted side of > > things. > > Sure but also what interface libparted needs? We don't have the time to do > it twice and checking it out isn't the highest priority now (for me).
Well, you could use the libparted filesystem handling as interface. struct _PedFileSystemOps { PedGeometry* (*probe) (PedGeometry* geom); int (*clobber) (PedGeometry* geom); PedFileSystem* (*open) (PedGeometry* geom); PedFileSystem* (*create) (PedGeometry* geom, PedTimer* timer); int (*close) (PedFileSystem* fs); int (*check) (PedFileSystem* fs, PedTimer* timer); PedFileSystem* (*copy) (const PedFileSystem* fs, PedGeometry* geom, PedTimer* timer); int (*resize) (PedFileSystem* fs, PedGeometry* geom, PedTimer* timer); PedConstraint* (*get_create_constraint) (const PedDevice* dev); PedConstraint* (*get_resize_constraint) (const PedFileSystem* fs); PedConstraint* (*get_copy_constraint) (const PedFileSystem* fs, const PedDevice* dev); }; Look at the include/parted directory in the parted source for everything you need. > In high level, resize could tell the constrains and do the resize but > for example, it's quite probably in some cases it needs to remount > the partition 3 times. Can [lib]parted live with that? I know nothing about ntfs, but i suppose it is somewhat silly to have to mount the partition while resizing it. > > I am interested by your opinion, what is it in parted that you dislike > > and why ? > > Mostly my lack of knowledge about its internals :) But seriously, > > - one of the most disliked one described below, even a patch is provided > to solve it (at least partly), > > http://mail.gnu.org/archive/html/bug-parted/2003-05/msg00046.html > > Knowing where things are in sector level is very important > occasionally. Notice that this is a critic of the parted program, it doesn't apply to the underlying libparted, which is what matters. Libparted uses geometries which are of the start/end/size kind of information, where all three of those are 64bit integers. > - decimal point usage in sizes is IMHO confusing, useless, ridiculous > (partition size is e.g. 315003089.536 bytes). If one needs better > resolution then he/she should use smaller units. But see above. Mmm, i don't know about this. > - no save/restore partition table functionality. Partitioning is very > messy, complicated, a lot of scenarios. When somethings goes wrong > (quite frequently if you read/filter many lists/etc) the only you can > say "sorry, maybe next time" (or try testdisk, gpart, etc -- I hear > better results than using parted's 'rescue'). Ok, i agree with this, but it could easily be implemented. That said, only the parted programs commits after each change, it is perfectly possible to have a libparted using program which does all the changes in the in-mem copy of the partition table, and do everything at once once you are happy with it. Doing filesystem creation is the problematic part, but i guess even that could be queued. > - offered choice 'ignore' to the users when it is _nonsense_ and would > destroy their data. It does as it were demonstrated several times. Again, a parted interface problem, not really related to libparted. This could easily be done in any graphical tool using libparted or something. > - "report this .... bug" instead of "check out ... for updates, etc" > Unfortunately there isn't any Changelog/FAQ on the Parted site, not to > mention link to the latest release. This is a real problem, but again not one of libparted per see, more one linked to the fact that there is no open CVS or whatever repository. This has to be solved soon, or parted will be forked or something. > > I personaly am a bit disapointed by the code quality of > > parted/libparted, > > Would you mind to express? Just a general impression, and the lack of accessible CVS repository doesn't help. The parted UI often dies for no reason at all, there are some garbage asserts in there which are leftover and makes thing fail horribly in some cases, and so on. I think the main problem is that there is need of more active maintaining and some cleanup of the internal stuff. > > and have been toying in doing a reimplmentation in ocaml, with maybe > > some coq-based prooves of good behavior, and having coq generate the > > corresponding code afterward. But i lack some time for this, and am > > not sure an ocaml-based libparted reimplementation would be welcome. > > I'm afraid it wouldn't be :) > > - most distros ship parted but I don't know any who ships ocaml most ship it, debian ships (and i am the maintainer of it) it. Lindows even use it for hardware detection and such in their installer. > - many people know C thus they might contribute but most doesn't > know ocaml and should learn it to do so Yeah, sure. > - you would throw away a lot of "hidden" knowledge in parted and > you should rediscover them the hard way Well, i already did part of that for implementing amiga partitioning table and filesystems. But then, you forgot the good sides, namely that a pure ocaml program cannot have runtime kind of errors, and that by doing a coq proof and and automated code generation from the proof for the critical pieces of the software, you would have a tool which was proven correct, which for partitioning handling would be a nice thing to have. Also, ocaml often means a tenfold reduction in code size for the same thing, which makes maintenance easier, and the fact that ocaml has functions as first class values, would make what libparted does much much easier. The objection i would have, would be more that you would have to bind in the ocaml runtime and virtual machine, which may be problematic in the small size initrd case of installers, and the fact that dynamic linking, altough possible, is not all that easy. > > BTW, the main problem of parted/libparted right now, is that there is no > > CVS repository of it, and that the code has been mostly unavailable > > since may 2003 or so. > > Yes and somebody who has the time to maintain it. In the worst case, we can always start an alioth project. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]