[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: virtiofsd: Where should it live?
From: |
Dr. David Alan Gilbert |
Subject: |
Re: virtiofsd: Where should it live? |
Date: |
Wed, 4 Dec 2019 12:04:18 +0000 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
* Markus Armbruster (address@hidden) wrote:
> Daniel P. Berrangé <address@hidden> writes:
>
> > On Tue, Dec 03, 2019 at 11:06:44AM +0000, Peter Maydell wrote:
> >> On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert <address@hidden> wrote:
> >> >
> >> > We seem to be coming to the conclusion something that:
> >> >
> >> > a) It should live in the qemu tree
> >> > b) It shouldn't live under contrib
> >> > c) We'll create a new top level, i.e. 'daemons'
> >> > d) virtiofsd will be daemons/virtiofsd
> >> >
> >> > Now, somethings I'm less clear on:
> >> > e) What else would move into daemons? It was suggested
> >> > that if we've got virtiofsd in there, then we should move
> >> > libvhost-user - which I understand, but then it's not a
> >> > 'daemons'.
> >> > Are there any otehr daemons that should move?
> >>
> >> I like the idea of a new top level directory, but I think
> >> 'daemons' is a bit too specific -- for instance it seems to
> >> me that qemu-img would be sensible to move out of the root,
> >> and that's not a daemon.
> >
> > Do we really need an extra directory level ?
>
> +1
>
> > IIUC, the main point against having $GIT_ROOT/virtiofsd is that
> > the root of our repo is quite cluttered already.
> >
> > Rather than trying to create a multi-level hierarchy which adds
> > a debate around naming, why not address the clutter by moving
> > *ALL* the .c/.h files out of the root so that we have a flatter
> > tree:
> >
> > $GITROOT
> > +- qemu-system
> > | +- vl.c
> > | +- ...most other files...
>
> Sounds good to me.
>
> > +- qemu-img
> > | +- qemu-img.c
>
> Perhaps this one can all go into existing block/, similar to how
> pr-manager-helper.c is in scsi/, and virtfs-proxy-helper.c is in fsdev/.
> Up to the block maintainers, of course.
>
> > +- qemu-nbd
> > | +- qemu-nbd.c
>
> block/ or nbd/?
>
> > +- qemu-io
> > | +- qemu-io.c
> > | +- qemu-io-cmds.c
>
> block/?
>
> > +- qemu-bridge-helper
>
> net/?
>
> > | ...
> > +- qemu-edid
>
> Has its own MAINTAINERS section, together with hw/display/edit* and
> include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good
> idea. Gerd?
>
> > +- qemu-keymap
>
> Not covered by MAINTAINERS. scripts/get_maintainer.pl --git-blame
> points to Gerd.
>
> > +- qga (already exists)
>
> Yes.
>
> > Then we can add virtiofsd and other programs at the root with no big
> > issue.
>
> We don't *have* to put each program into its own directory. Simple ones
> could also share one. We just need a directory name.
So what do you think of Paolo's suggestion of putting virtiofsd in
fsdev (mkdir fsdev/9p && mv fsdev/* fsdev/9p && mkdir fsdev/virtiofsd )
Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK