linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <openosd@gmail.com>
To: "Schumaker, Anna" <Anna.Schumaker@netapp.com>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"boaz@plexistor.com" <boaz@plexistor.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Cc: "Manole, Sagi" <Sagi.Manole@netapp.com>,
	"swhiteho@redhat.com" <swhiteho@redhat.com>,
	"amir73il@gmail.com" <amir73il@gmail.com>,
	"rwheeler@redhat.com" <rwheeler@redhat.com>,
	"mszeredi@redhat.com" <mszeredi@redhat.com>,
	"Golander, Amit" <Amit.Golander@netapp.com>,
	"jmoyer@redhat.com" <jmoyer@redhat.com>
Subject: Re: [RFC PATCH 04/17] zuf: zuf-core The ZTs
Date: Thu, 28 Feb 2019 19:01:07 +0200	[thread overview]
Message-ID: <0d59f02e-f9ed-5d86-09ec-25f2421e3f7c@gmail.com> (raw)
In-Reply-To: <19e36daae0896060c3280637d7a3fcc9aa8cee35.camel@netapp.com>

On 26/02/19 20:34, Schumaker, Anna wrote:
> On Tue, 2019-02-19 at 13:51 +0200, Boaz harrosh wrote:
<>
>> zuf-core established the communication channels with the ZUS
>> User Mode Server.
>>
>> In this patch we have the core communication mechanics.
>> Which is the Novelty of this project.
>> (See previous submitted documentation for more info)
>>
>> Users will come later in the patchset
>>
<>
>> +static inline int relay_fss_wait(struct relay *relay)
>> +{
>> +       int err;
>> +
>> +       relay->fss_waiting = true;
>> +       relay->fss_wakeup = false;
>> +       err =  wait_event_interruptible(relay->fss_wq, relay->fss_wakeup);
>> +
>> +       return err;
> 
> Could you just do: "return wait_event_interruptible()" directly, instead of
> using the err variable?
> 

Totally there used to be a dbg_print here there for the reminder of that time
Will change ...

>> +}
>> +
<>
>> +static struct zufc_thread *_zt_from_cpu(struct zuf_root_info *zri,
>> +                                       int cpu, uint chan)
>> +{
>> +       return per_cpu_ptr(zri->_ztp->_all_zt[chan], cpu);
>> +}
>> +
>> +static int _zt_from_f(struct file *filp, int cpu, uint chan,
>> +                     struct zufc_thread **ztp)
>> +{
>> +       *ztp = _zt_from_cpu(ZRI(filp->f_inode->i_sb), cpu, chan);
>> +       if (unlikely(!*ztp))
>> +               return -ERANGE;
>> +       return 0;
> 
> I'm curious if there is a reason you did it this way instead of making use of
> the ERR_PTR() macro to return ztp directly?
> 

For one now looking at it I hate the name its wrong. I will change that. It is done
like that because it used to be used in many places and I did not want every place
to have its print and invent its own error code.

But now it has a single user I might just fold it into its only user.
All other places must use _zt_from_f_private. Cool I'll kill it.

>> +}
>> +
<>

Thanks, will fix
Boaz

>> +static int _zu_init(struct file *file, void *parg)
>> +{
>> +       struct zufc_thread *zt;
>> +       int cpu = smp_processor_id();
>> +       struct zufs_ioc_init zi_init;
>> +       int err;
>> +
>> +       err = copy_from_user(&zi_init, parg, sizeof(zi_init));
>> +       if (unlikely(err)) {
>> +               zuf_err("=>%d\n", err);
>> +               return err;
>> +       }
>> +       if (unlikely(zi_init.channel_no >= ZUFS_MAX_ZT_CHANNELS)) {
>> +               zuf_err("[%d] channel_no=%d\n", cpu, zi_init.channel_no);
>> +               return -EINVAL;
>> +       }
>> +
>> +       zuf_dbg_zus("[%d] aff=0x%lx channel=%d\n",
>> +                   cpu, zi_init.affinity, zi_init.channel_no);
>> +
>> +       zi_init.hdr.err = _zt_from_f(file, cpu, zi_init.channel_no, &zt);
>> +       if (unlikely(zi_init.hdr.err)) {
>> +               zuf_err("=>%d\n", err);
>> +               goto out;
>> +       }
>> +
>> +       if (unlikely(zt->hdr.file)) {
>> +               zi_init.hdr.err = -EINVAL;
>> +               zuf_err("[%d] !!! thread already set\n", cpu);
>> +               goto out;
>> +       }
>> +
>> +       relay_init(&zt->relay);
>> +       zt->hdr.type = zlfs_e_zt;
>> +       zt->hdr.file = file;
>> +       zt->no = cpu;
>> +       zt->chan = zi_init.channel_no;
>> +
>> +       zt->max_zt_command = zi_init.max_command;
>> +       zt->opt_buff = vmalloc(zi_init.max_command);
>> +       if (unlikely(!zt->opt_buff)) {
>> +               zi_init.hdr.err = -ENOMEM;
>> +               goto out;
>> +       }
>> +       _fill_buff(zt->opt_buff, zi_init.max_command / sizeof(ulong));
>> +
>> +       file->private_data = &zt->hdr;
>> +out:
>> +       err = copy_to_user(parg, &zi_init, sizeof(zi_init));
>> +       if (err)
>> +               zuf_err("=>%d\n", err);
>> +       return err;
>> +}
>> +
>> +struct zufc_thread *_zt_from_f_private(struct file *file)
>> +{
>> +       struct zuf_special_file *zsf = file->private_data;
>> +
>> +       WARN_ON(zsf->type != zlfs_e_zt);
>> +       return container_of(zsf, struct zufc_thread, hdr);
>> +}
>> +
>> +/* Caller checks that file->private_data != NULL */
>> +static void zufc_zt_release(struct file *file)
>> +{
>> +       struct zufc_thread *zt = _zt_from_f_private(file);
>> +
<>

  reply	other threads:[~2019-02-28 17:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-19 11:51 [RFC PATCH 00/17] zuf: ZUFS Zero-copy User-mode FileSystem Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 01/17] fs: Add the ZUF filesystem to the build + License Boaz harrosh
2019-02-20 11:03   ` Greg KH
2019-02-20 14:55     ` Boaz Harrosh
2019-02-20 19:40       ` Greg KH
2019-02-26 17:55   ` Schumaker, Anna
2019-02-28 16:42     ` Boaz Harrosh
2019-02-19 11:51 ` [RFC PATCH 02/17] zuf: Preliminary Documentation Boaz harrosh
2019-02-20  8:27   ` Miklos Szeredi
2019-02-20 14:24     ` Boaz Harrosh
2019-02-19 11:51 ` [RFC PATCH 03/17] zuf: zuf-rootfs Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 04/17] zuf: zuf-core The ZTs Boaz harrosh
2019-02-26 18:34   ` Schumaker, Anna
2019-02-28 17:01     ` Boaz Harrosh [this message]
2019-02-19 11:51 ` [RFC PATCH 05/17] zuf: Multy Devices Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 06/17] zuf: mounting Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 07/17] zuf: Namei and directory operations Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 08/17] zuf: readdir operation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 09/17] zuf: symlink Boaz harrosh
2019-02-20 11:05   ` Greg KH
2019-02-20 14:12     ` Boaz Harrosh
2019-02-19 11:51 ` [RFC PATCH 10/17] zuf: More file operation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 11/17] zuf: Write/Read implementation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 12/17] zuf: mmap & sync Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 13/17] zuf: ioctl implementation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 14/17] zuf: xattr implementation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 15/17] zuf: ACL support Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 16/17] zuf: Special IOCTL fadvise (TODO) Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 17/17] zuf: Support for dynamic-debug of zusFSs Boaz harrosh
2019-02-19 12:15 ` [RFC PATCH 00/17] zuf: ZUFS Zero-copy User-mode FileSystem Matthew Wilcox
2019-02-19 19:15   ` Boaz Harrosh

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=0d59f02e-f9ed-5d86-09ec-25f2421e3f7c@gmail.com \
    --to=openosd@gmail.com \
    --cc=Amit.Golander@netapp.com \
    --cc=Anna.Schumaker@netapp.com \
    --cc=Sagi.Manole@netapp.com \
    --cc=amir73il@gmail.com \
    --cc=boaz@plexistor.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=rwheeler@redhat.com \
    --cc=swhiteho@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).