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

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



On Mon, Nov 16, 2015 at 10:22:41AM -0700, Linda wrote:
> 
> 
> On 11/16/2015 9:51 AM, Wei Liu wrote:
> >On Mon, Nov 16, 2015 at 09:36:24AM -0700, Linda wrote:
> >>Hi Wei,
> >>
> >>On 11/16/2015 8:16 AM, Wei Liu wrote:
> >>>Hi Linda
> >>>
> >>>On Fri, Nov 13, 2015 at 10:23:22AM -0700, Linda wrote:
> >>>>Hello,
> >>>>      I worked this summer as an intern under Julien Grall and Wei Liu.  
> >>>> My
> >>>>project was to develop a prototype/proof of concept xen front/back end for
> >>>>the 9p file system.  I mostly hacked the virtio 9p system.
> >>>>     This project was not complete, at the end of the summer.  Julien said
> >>>>that you all wanted to include this in the next release of xen in January,
> >>>>and offered to take it over.  I told Julien I wanted to continue working 
> >>>>on
> >>>>it, which I have been doing, very much in the background.
> >>>>     I came upon a bug in my code recently that made me aware that I am 
> >>>> not
> >>>>clear what the expectation for what I deliver should be: i.e., whether 
> >>>>it's
> >>>>still a prototype, or whether this should be production software.
> >>>>     Right now, I do not modify the toolstack (I never learned how), but
> >>>>rather start and pause my guest, and then modify xenstore, manually.   I 
> >>>>can
> >>>>fix my bug in the same manner, but this will limit the usefulness of what 
> >>>>I
> >>>>deliver.  To do more will hit up against the limitations of my time and
> >>>>knowledge.
> >>>>     So please let me know what you're expecting, especially wrt the user
> >>>>interface, and when I would need to complete everything for this release.
> >>>>
> >>>If I interpret this correctly, you have a prototype that's working? Do
> >>>you have your code somewhere?
> >>No.  I hit a bug that I would fix differently, depending on my goal.
> >>>I think we would still like to include it in next release if possible --
> >>>that would require a properly implemented solution, not just a
> >>>prototype.  Let's assess the current situation and then decide what to
> >>The situation is, given my current knowledge and what my availability has
> >>been (it may improve), I can either:
> >>     a.  Get a decent prototype working by the end of the year.  This would
> >>have certain values pre-written in xenstore, that I'm currently doing
> >>manually.  There are potentially some issues with mounting that I suspect
> >>need to be different for xen than they are for virtio - so either way, I
> >>need a clarification of how xen people want this to work.
> >>     b.  Make sure what I've written is working, and pass it on to someone
> >>else to update the toolstack, and resolve the issues, described above.  In
> >>this scenario, I would need to know how much time that someone would need
> >>and just devote a week to getting this to them.
> >>
> >Your description is too vague. I don't have clear idea what kind of bug
> >you encountered and what suggestion I can give.
> 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.

> >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.

If we end up taking over the project, we will still attribute the
initial implementation to you.

Wei.

_______________________________________________
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®.