On Thu, Oct 24, 2019 at 06:59:33AM -0400, Michael S. Tsirkin wrote: > On Mon, Oct 21, 2019 at 03:33:57PM +0100, Dr. David Alan Gilbert wrote: > > * no-re...@patchew.org (no-re...@patchew.org) wrote: > > > Patchew URL: > > > https://patchew.org/QEMU/20191021105832.36574-1-dgilb...@redhat.com/ > > > > > > > > > > > > Hi, > > > > > > This series seems to have some coding style problems. See output below for > > > more information: > > > > > > Subject: [PATCH 00/30] virtiofs daemon (base) > > > Type: series > > > Message-id: 20191021105832.36574-1-dgilb...@redhat.com > > > > > > === TEST SCRIPT BEGIN === > > > #!/bin/bash > > > git rev-parse base > /dev/null || exit 0 > > > git config --local diff.renamelimit 0 > > > git config --local diff.renames True > > > git config --local diff.algorithm histogram > > > ./scripts/checkpatch.pl --mailback base.. > > > > Expecting checkpatch to be broken here; most of the files > > follow FUSE's formatting. > > > > Dave > > I wonder what do others think about this. > One problem with such inconsistencies is that people tend to copy code > around, which tends to result in a mess.
IIUC, most of this code is simpy copied as-is from the fuse or linux git repos. I'm wondering what the intention is for it long term ? For header files, I would have expected us to be able to compile against the -devel package provided by the kernel or fuse packages. I can understand if we want to import the headers if the VSOCK additions to them are not yet widely available in distros though. If this is the case we should put a time limit on how long we'd keep these copied headers around for before dropping them. It would be fine to violate QEMU coding style in this case as its not code QEMU would "maintain" long term - just a read-only import. The source files though, we appear to then be modifying locally, which suggests they'll live in our repo forever. In this case I'd expect to have compliance with QEMU coding standards. I'm surprised we need to copy so much in from fuse though. Is there a case to be made for fuse to provide a library of APIs for people who are building fuse daemons to link against, instead of copy & fork ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
