[parted-devel] Regarding UFS support in libparted

[David Cantrell]

On Tue, 1 Jan 2008 09:58:34 +1300
"Avinash Malik" <avimalik at gmail.com> wrote:

> Hello,
>          I need complete ufs-support in libparted, since its missing I
> decided to write code myself. The ufs-support which I am looking for
> is something like solaris (newfs/mkfs).
> 
> 
> The first thing which I need is ufs-fs creation capability.
> something like this....
> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/ufs/mkfs/mkfs.c#417

Please do not use code from OpenSolaris in parted.  The licenses are incompatible and we [the project] can get in trouble if code is found from OpenSolaris in parted.  This goes for reading the code and then rewriting it from scratch.  The implementation will be tainted.

> My main working platform is linux...
> There are a lot of structures like cylinder groups and dinodes which
> need to be present for this to work...
> 
> I was thinking of including linux-source-header files in the libparted
> ufs infrastructure to get this support, instead of replicating all the
> structures again in libparted. Is there a better solution than this?

Check for them on the target system and enable UFS support if they are found.  Modification to configure.ac and then source files to include the header conditionally.

> I wanted to know why, does libparted in ufs.c replicate the
> ufs_super_block structure, instead of just using the one in linux
> ufs_fs.h file. Is it because of support for GNU/BeOS.. since I am not
> familiar with GNU/BeOS code I am kinda lost here.
> 
> Please cc the reply since I am not subsribed to the mailing list....

GNU parted originally tried to be free of any external libraries and stand on its own.  GNU Hurd (not BeOS, different product entirely) was a driving factor as Hurd couldn't depend on external libraries found on Linux or Solaris or anything like that.  Mostly for portability between different operating systems.  This has proven difficult to maintain as well as preventing us from working with new filesystem features (ext3, for instance).  We are in the slow process of moving over the filesystem code to use external libraries where possible.

Hope that helps.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20080105/1c96f0bb/attachment.pgp