All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
Cc: Phillip Potter <phil@philpotter.co.uk>,
	dushistov@mail.ru, David.Laight@aculab.com,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: ufs: Remove switch statement from ufs_set_de_type function
Date: Sun, 21 Oct 2018 00:07:34 +0100	[thread overview]
Message-ID: <20181020230734.GO32577@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20181020222637.GA3477@bombadil.infradead.org>

On Sat, Oct 20, 2018 at 03:26:37PM -0700, Matthew Wilcox wrote:
> On Sat, Oct 20, 2018 at 11:09:57PM +0100, Phillip Potter wrote:
> > Remove switch statement from ufs_set_de_type function in fs/ufs/util.h
> > header and replace with simple assignment. For each case, S_IFx >> 12
> > is equal to DT_x, so in valid cases (mode & S_IFMT) >> 12 should give
> > us the correct file type. It is expected that for *nix compatibility
> > reasons, the relation between S_IFx and DT_x will not change. For
> > cases where the mode is invalid, upper layer validation catches this
> > anyway, so this improves readability and arguably performance by
> > assigning (mode & S_IFMT) >> 12 directly without any jump table
> > or conditional logic.
> 
> Shouldn't we also do this for other filesystems?  A quick scan suggests
> someone should at least look at xfs, ubifs, squashfs, romfs, ocfs2,
> nilfs2, hfsplus, f2fs, ext4, ext2, exofs, coda, cifs & btrfs.

Do what for other filesystems?  E.g. ext* has the type cached in directory
entry - as a straight enum, so encoding is needed.  Which we do.  ocfs2
is pretty certain to have it in ext*-compatible layout.  ubifs stores
them in another enum of its own (also handled).  XFS - another enum (present
on some layout variants), etc.

And... CIFS?  Seriously?  This stuff is about encoding used to cache the
file type in directory entry; how the bleeding hell would CIFS _client_
get anywhere near that?

  reply	other threads:[~2018-10-21  7:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-20 22:09 [PATCH] fs: ufs: Remove switch statement from ufs_set_de_type function Phillip Potter
2018-10-20 22:26 ` Matthew Wilcox
2018-10-20 23:07   ` Al Viro [this message]
2018-10-21  5:30   ` Amir Goldstein
2018-10-21  9:57     ` Phillip Potter
2018-10-21 11:02       ` Amir Goldstein
2018-10-22  8:20         ` Phillip Potter
  -- strict thread matches above, loose matches on Subject: below --
2018-10-17 12:34 Phillip Potter
2018-10-17 10:08 Phillip Potter
2018-10-17 10:11 ` David Laight
2018-10-17 23:33   ` Al Viro
2018-10-18 10:19     ` Phillip Potter
2018-10-09 13:16 Phillip Potter
2018-10-02 16:41 Phillip Potter

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=20181020230734.GO32577@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=David.Laight@aculab.com \
    --cc=dushistov@mail.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phil@philpotter.co.uk \
    --cc=willy@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.