All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <aliguori@amazon.com>
Subject: [Qemu-devel] 9pfs-local: the security models enum?
Date: Thu, 05 Mar 2015 00:17:10 +0300	[thread overview]
Message-ID: <54F77656.4060907@msgid.tls.msk.ru> (raw)

I noticed that most file operations in hw/9pfs/virtio-9p-local.c
are modelled like this:

    if (fs_ctx->export_flags & V9FS_SM_MAPPED) {
       /* MAPPED version */
    } else if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE) {
       /* MAPPED_FILE version */
    } else if ((fs_ctx->export_flags & V9FS_SM_PASSTHROUGH) ||
               (fs_ctx->export_flags & V9FS_SM_NONE)) {
       /* PASSTHROUGH or NONE version */
    } else {
       /* this is my addition to show the "default" case */
       err = -1;
    }

I've 2 questions about this.

First, why we always have the "else" case, is it really
possible to have export_flags set in such a way so that
none of the 4 conditions are true?  If there's exactly
4 possible variants without the "else", it is possible
to simplify most of these functions greatly.

And second, why this code does not use a switch, why all
these ifs?  switch statement is good because the compiler
can check possible additional cases which are added later,
if that's the reason why we have this "else" to start with.
Something like this:

 switch (fs_ctx->export_flags & V9FS_SEC_MASK) {
   case V9FS_SM_MAPPED_FILE:
   ...
 }

(it is not that easy for the compiler to check this in
this form, so maybe security model should be moved from
export_flags to an additional field?)

Thanks,

/mjt

                 reply	other threads:[~2015-03-04 21:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=54F77656.4060907@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=aliguori@amazon.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.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.