All of lore.kernel.org
 help / color / mirror / Atom feed
From: hujianyang <hujianyang@huawei.com>
To: Daniel <daniel@makrotopia.org>, Artem Bityutskiy <dedekind1@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v2] ubifs: respect MS_SILENT mount flag
Date: Wed, 28 May 2014 10:11:00 +0800	[thread overview]
Message-ID: <538545B4.7070103@huawei.com> (raw)
In-Reply-To: <5384B772.4030506@makrotopia.org>

Hi Daniel and Artem,

> 
> You can test this by trying to mount a non-empty volume which does not contain a
> UBIFS superblock (but e.g. squashfs or a U-Boot environment) with
> mount -t ubifs -o silent /dev/ubiX_Y /mnt
> This should fail without creating any klog lines.
> 

I think disabling log message in this case is needed. But I'm sorry to say
I don't like just adding a new parameter to ubifs_read_node in this way
because this silent flag seems only used during mount. This adding makes the
parameters different in ubifs_read_node and ubifs_write_node, also not good
for reading code.

How about to add a separate func ubifs_read_node_silent to instead this
ubifs_read_node in ubifs_read_sb_node? I think we could do more proper work
in this new function.

> 
> However, this is probably distribution-specific hackery, but independently of
> that, UBIFS should still respect the MS_SILENT flag just like all other
> filesystems do.
> 

Do you get some more error messages not only in ubifs_read_node during mount?
I think this is a good suggestion. Current code do not use @silent in
ubifs_fill_super and we should do some work to enable it like other filesystems.

Thanks!

Hu

  reply	other threads:[~2014-05-28  2:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-17  1:55 [PATCH] ubifs: respect MS_SILENT mount flag Daniel Golle
2014-05-27 12:18 ` Artem Bityutskiy
2014-05-27 14:11   ` [PATCH v2] " Daniel Golle
2014-05-27 14:56     ` Artem Bityutskiy
2014-05-27 16:04       ` Daniel
2014-05-28  2:11         ` hujianyang [this message]
2014-05-28  8:01           ` Artem Bityutskiy
2014-05-28  8:07             ` Bityutskiy, Artem
2014-05-28  8:14               ` Artem Bityutskiy
2014-05-28  8:28                 ` Artem Bityutskiy
2014-05-28  8:42                   ` hujianyang
2014-05-28  9:29                     ` Artem Bityutskiy
2014-05-30 22:01                   ` [PATCH v3] " Daniel Golle
2014-05-30 23:20                     ` Brian Norris
2014-05-30 23:32                       ` [PATCH v4] " Daniel Golle
2014-05-31  0:01                       ` [PATCH v5] " Daniel Golle
2014-06-02  7:59                         ` Artem Bityutskiy
2014-06-02 13:51                           ` [PATCH v6] " Daniel Golle
2014-06-02 15:01                             ` Artem Bityutskiy

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=538545B4.7070103@huawei.com \
    --to=hujianyang@huawei.com \
    --cc=daniel@makrotopia.org \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.