From: Coly Li <coyli@suse.de>
To: Theodore Tso <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Andreas Dilger <adilger@clusterfs.com>
Subject: Re: [PATCH] e2fsprogs: remove fragment support (V3)
Date: Mon, 13 Aug 2007 05:59:39 +0800 [thread overview]
Message-ID: <46BF82CB.7060304@suse.de> (raw)
In-Reply-To: <20070812212955.GD21719@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]
Theodore Tso wrote:
> On Mon, Aug 13, 2007 at 12:33:26AM +0800, Coly Li wrote:
>> Theodore,
>>
>> Another question of mine is for the .po files: Once I modify a string from _(""), should I mofify
>> all the corresponded strings from all .po files ?
>
> No, don't bother. Periodically I run "make update-pot" in the po
> directory, which updates the e2fsprogs.pot file, followed by a "make
> update-po" which remove the strings from the .po files.
>
>> Oops, I thought that issues from my email client. OK, next time when
>> I send patch I will use MIME-PGP.
>
> Yeah, it's protecting the "-----BEGIN PGP SIGNED MESSAGE-----" header
> line, so it has to add "- " to all lines that begin with "-". Using
> MIME-PGP means that we use the MIME message boundaries instead.
>
>>> In addition, for now, I'd like to keep the code which checks the
>>> remaining fragment fields in the inode and superblock since they act
>>> as a safety check to make sure the filesystem is sane and we don't
>>> have garbage there. The checksum fields will obviate this need, but
>>> keeping the checks there for ext2/ext3 filesystems seem like a good
>>> idea.
>> My idea is:
>> 1) Modify names of related fields of superblock and inode. to avoid others using these field in future.
>> 2) Keep checking code for the modified fields. to make source code robust.
>
> Comments in the header file is probably enough, I think. Changing the
> names fields just causes a lot of code churn....
>
>>> Dropping the union is probably fine, since at this point it looks
>>> pretty clear that both the Hurd and Masix is dead. But let's do the
>>> cleanups a little at a time, and I'd probably start with just removing
>>> the cruft from the mke2fs options and man pages.
>> Sure, I agree with you :-)
>
> I did some checking, and it looks like Hurd is still using basic ext2.
> Some grad student did a ext3 driver for Hurd, but it's unstable and
> was apparently last touched in 2005 (the Ph.D. thesis was done in 2003
> iirc). Sigh...
>
> Unfortunately, I did some checking and it looks like there are some
> crazy people that are still actively working on a Debian GNU/Hurd
> project. So let's leave the Hurd stuff in for now. There may be some
> issues where they will need to drop using ext2 for licensing reasons,
> but let's save this cleanup for later. It doesn't cost us much to
> leave it in, after all.
>
Sure, I will only post a patch for removing masix. For hurd, let's wait and see :-)
> - Ted
Thanks for your comment :-)
Best regards.
--
Coly Li
SuSE PRC Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
prev parent reply other threads:[~2007-08-12 21:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-10 17:13 [PATCH] e2fsprogs: remove fragment support (V3) Coly Li
2007-08-10 18:45 ` Andreas Dilger
2007-08-12 16:24 ` Coly Li
2007-08-12 3:31 ` Theodore Tso
2007-08-12 16:33 ` Coly Li
2007-08-12 21:29 ` Theodore Tso
2007-08-12 21:59 ` Coly Li [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46BF82CB.7060304@suse.de \
--to=coyli@suse.de \
--cc=adilger@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.