On 13.03.2018 19:36, Boaz Harrosh wrote:
>
> zuf-core established the communication channels with
> the zus UM Server.
>
> zuf-root is a psuedo FS that the zus communicates through,
> registers new file-systems. receives new mount requests.
>
> In this patch we have the bring up of that special FS, and
> the core communication mechanics. Which is the Novelty
> of this code submission.
>
> The zuf-rootfs (-t zuf) is usually by default mounted on
> /sys/fs/zuf. If an admin wants to run more server applications
> (Note that each server application supports many types of FSs)
> He/she can mount a second instance of -t zuf and point the new
> Server to it.
>
> (Otherwise a second instance attempting to communicate with a
> busy zuf will fail)
>
> TODO: How to trigger a first mount on module_load. Currently
> admin needs to manually "mount -t zuf none /sys/fs/zuf"
>
> Signed-off-by: Boaz Harrosh <boazh@xxxxxxxxxx>
<snip>
> + while (!relay_is_fss_waiting(&zt->relay)) {
> + mb();
Not something for this early in the development cycle but something to
keep in mind:
Always document all assumptions re. memory barriers usage + intended
pairing scenario otherwise it's very hard to reason whether this is
correct or not. In fact barriers without comments are considered broken.
> + if (unlikely(!zt->file))
> + return -EIO;
> + zuf_dbg_err("[%d] can this be\n", cpu);
> + /* FIXME: Do something much smarter */
> + msleep(10);
> + mb();
> + }
> +
> + zt->next_opt = hdr;
> + zt->pages = pages;
> + zt->nump = nump;
> +
> + relay_fss_wakeup_app_wait(&zt->relay, NULL);
> +
> + return zt->file ? hdr->err : -EIO;
> +}
<snip>
