All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Theodore Tso <tytso@MIT.EDU>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [E2FSPROGS, RFC] New mke2fs types parsing
Date: Tue, 18 Mar 2008 00:16:53 -0500	[thread overview]
Message-ID: <47DF5045.1000108@redhat.com> (raw)
In-Reply-To: <20080318042339.GO8368@mit.edu>

Theodore Tso wrote:

> The question then is what to do when the user specifies something
> non-sensical, where they put the filesystem type last.  

Well, I'd say do what they asked, treat the [filesystem type] stanza
just like any other, and anything in it which may override previous
stanzas, does.

> One approach
> would be to use a two-pass algorithm, where you first scan the list
> for any filesystem type or size types, and if so, you suppress
> prefixing the list with the fs_type and size_type.  I think that's
> what you are suggesting.

Not exactly...

> Then there was my approach, which was admittedly partially influenced
> by what was quicker and easier to code, which only checked the
> expected position.

Well, I think that what I'm suggesting (but it's late, and I'm tired, so
it's hard for me to tell for sure... ;) is that there is no special
anything.  You simply take the specified -T arguments in order, and use
that as the search/override order for any setting found in the stanzas
specified.  This would probably be simplest to code, actually, as well
as simplest to document, and even most powerful/flexible for the user.

But, I suppose I can live with

     -T [fs_type,][size_type,]user_type[,additional_type...]

which is reasonably clear, though... we just need to document that there
are 7 special stanza names in 2 categories, which the code will put
there *for* you if you don't put it them the right place, yourself.
It's just, IMHO, a more complicated and restricted specification for the
option.

-Eric

  reply	other threads:[~2008-03-18  5:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 14:06 [E2FSPROGS, RFC] New mke2fs types parsing Theodore Ts'o
2008-02-20 18:51 ` Eric Sandeen
2008-02-20 22:20   ` Theodore Tso
2008-02-20 22:28     ` Eric Sandeen
2008-02-21  8:52     ` Andreas Dilger
2008-02-21 13:35       ` Theodore Tso
2008-03-17 21:29     ` Eric Sandeen
2008-03-18  2:20       ` Theodore Tso
2008-03-18  3:23         ` Eric Sandeen
2008-03-18  4:23           ` Theodore Tso
2008-03-18  5:16             ` Eric Sandeen [this message]
2008-03-18 11:01               ` Theodore Tso
2008-03-18 13:11                 ` Eric Sandeen
2008-03-18 13:52                   ` Theodore Tso
2008-03-18 16:06                     ` Eric Sandeen
2008-03-20 19:17                     ` Eric Sandeen
2008-03-20 20:49                       ` Theodore Tso
2008-03-19  3:36                 ` Andreas Dilger

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=47DF5045.1000108@redhat.com \
    --to=sandeen@redhat.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.