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);
>> +
<>
next prev parent 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).