[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 9p file system for xen





On 11/17/2015 11:35 AM, Neil Sikka wrote:
How does Linda's work relate to Wei's patches available here (I didnt see them in Xen-4.6.0):

http://downloads.xen.org/Wiki/VirtioOnXen/qemu-01-xenpv-exec.patch
http://downloads.xen.org/Wiki/VirtioOnXen/qemu-02-virtio-for-pv.patch
I'll let Wei answer this.Â

Also, since 9p is being worked on, which is a filesystem that should be implemented in a kernel rather than a hypervisor, are you looking to contribute this driver to the Linux kernel?
What I did was write new kernel routines and new Qemu routines, as well as modifying a few existing Qemu files. The initialization is currently done manually by modifying xenstore. This is the only code that properly belongs in the hypervisor.

I hope this clarifies things.

Linda

On Mon, Nov 16, 2015 at 10:02 PM, Linda <lindaj@xxxxxxxx> wrote:
Hi Wei,

On 11/16/2015 10:35 AM, Wei Liu wrote:
On Mon, Nov 16, 2015 at 10:22:41AM -0700, Linda wrote:
...

The bug is a timing issue:Â During virtio's probe step, on the front end, it
initialized the mount path. Since at that time, the front end doesn't have
access to the back end's entries in xenstore (AFIACT), I either need to put
it in xenstore prior to starting, or move the access to this information to
later in the initialization.

Note, I used the past tense on what virtio did, as of last summer: when I
looked at it last week, it appears to have changed since I first used it as
a template.  I need to investigate this further.

OK.

Finally, I've made no provision for how to mount more than one file system
for the same guest. This is a feature that virtio provides for in the
front-end code (as do I), but I am unclear about how this works in the
back-end or at the user level. This is what I suspect will be different in
xen, and I'd like some input on what it should look like.
I think this comes down to how your design the xenstore protocol to
represent different mount points.
And just reading this gave me the answer I need.

The code freeze for next release is going to be end of March next year.
As software engineer often overestimates the progress he or she can
make, I would say we shall aim for getting something working as soon as
possible. Get the design straight and something clean by the end of this
year would be good.
Sounds good to me. I'm happy to keep working on this. I just didn't want
to find myself in a position where I needed to pass this on to someone else,
but I didn't give that person enough time to finish what I'd done.
Depending on the situation, I can take over the code. You've done enough
for this project and we don't really want you to work on it for free --
we don't have provision for more funding at the moment.
Understood.
If we end up taking over the project, we will still attribute the
initial implementation to you.
  Thanks. Julien said essentially the same thing. Right now, I'm working on average, less than 10 hours/week, so it's enough to keep my mind engaged, but it doesn't interfere with anything else.
  I will be working for pay, in some capacity (TBD), after the first of the year. ÂRight now, I'm working to line things up.
  Unless something changes drastically, I'll continue to work on this until the end of the year. I'll start by cleaning things up, and keep it that way, so no matter what happens, you, or Julien, can take it over.

Linda


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel



--
Twitter: @neilsikka

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.