public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Gray Remlin <gryrmln@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/4] UBI/UBIFS: Prevent UBI partition change while UBIFS is mounted
Date: Tue, 02 Nov 2010 00:31:50 +0000	[thread overview]
Message-ID: <4CCF5BF6.2070806@gmail.com> (raw)
In-Reply-To: <20101101190631.D5B191524F4@gemini.denx.de>

On 01/11/10 19:06, Wolfgang Denk wrote:
> Dear Stefan Roese,
> 
> In message <201011011420.35851.sr@denx.de> you wrote:
>>
>>>> Only allow (re-)assignment to an UBI partition/device when UBIFS is
>>>> currently not mounted. Otherwise the following UBIFS commands will
>>>> crash.
>>>>
>>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>>> ---
>>>>
>>>>  common/cmd_ubi.c   |   13 +++++++++++++
>>>>  common/cmd_ubifs.c |    5 +++++
>>>>  2 files changed, 18 insertions(+), 0 deletions(-)
>>>
>>> I'm a bit biased here - from standard Unix command usage it seems
>>> natural that you have to manually umount first, but then we have very
>>> smple device handling in U-Boot, with always only one device in
>>> access.  Would it not make sense to auto-unmount in case the user
>>> switches the device?
>>
>> I can implement it this way if preferred. I'll prepare a new for this later.
> 
> As mentioned - I am not sure what would be best here.
> 
> What is your own position?
> 
> And: anybody else to comment?
> 
> Best regards,
> 
> Wolfgang Denk
> 
As a 'User' what matters the most to me is command user interface
consistency
(yes I want the impossible) regardless of the filesystem\device type.

For example to load uImage, I want 'load <device>:<partition>:<file>'
whether
it be an ide device with ext3 filesystem or a mmc device with ubifs.

If a filesystem needs to be mounted for some devices\commands but not others
then it should 'just happen' when needed. As a 'User' my only interest
is the
desired end result with the minimum of brainpower input. I want all related
commands to take the same arguments in the same order. I want to be able to
use them without understanding (technically) what they do.

An acceptable alternative would be to 'select <device>:<partition>' then
have
all further commands refer to said '<device>:<partition>' without restating.
But I would want all commands to work that way.

And personally, I like terse commands, but I know others hate them....Oh
well.

As a developer I know this is unrealistic...but a 'User' what matters
the most
to me is command user interface consistency!

  reply	other threads:[~2010-11-02  0:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-28 12:09 [U-Boot] [PATCH 4/4] UBI/UBIFS: Prevent UBI partition change while UBIFS is mounted Stefan Roese
2010-10-29 14:01 ` Ben Gardiner
2010-10-29 21:06 ` Wolfgang Denk
2010-11-01 13:20   ` Stefan Roese
2010-11-01 19:06     ` Wolfgang Denk
2010-11-02  0:31       ` Gray Remlin [this message]
2010-11-02 10:49       ` Stefan Roese
2010-11-02 14:33         ` Ben Gardiner
2010-11-14 21:06         ` Wolfgang Denk

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=4CCF5BF6.2070806@gmail.com \
    --to=gryrmln@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox