wrote:
Eric Van Hensbergen wrote on Mon, Apr 13, 2015 at 04:05:28PM +:
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according to the protocol. fid 3 and fid 2 are both clones of fid 1.
Right, they're clone fids, but nothing in the protocol says what should
happen
That patch looks fine by me. Happy to put it in the queue. Thanks Al.
On Tue, Apr 14, 2015 at 11:07 AM Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Apr 13, 2015 at 04:05:28PM +, Eric Van Hensbergen wrote:
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according to the protocol. fid 3 and fid 2 are both clones of fid 1.
However, thanks for the alternative workaround. If you get a chance, can
you check that my change to the client to partially fix this for the other
servers
** Bug watch added: Red Hat Bugzilla #1114221
https://bugzilla.redhat.com/show_bug.cgi?id=1114221
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file
I've done some digging from the client side. As is mentioned in Miklos'
original patch (which appears to have been shot down) the higher level
implementation appear to be broken for this. Here's what the code looks
like for fstat in fs/stat.c:
int vfs_fstat(unsigned int fd, struct kstat *stat)
On Sun, Apr 12, 2015 at 9:09 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Apr 12, 2015 at 12:42:35PM -, Eric Van Hensbergen wrote:
In other words, it only uses the open fd to derrive a path and then
executes the getattr off of that path. If that path no longer exists
(because
Yeah, that's probably overdue -- it should gracefully downgrade to 9p2000.u
and/or 9p2000 anyways.
-eric
On Fri, Mar 1, 2013 at 1:38 PM, H. Peter Anvin h...@zytor.com wrote:
On 02/28/2013 04:24 AM, M. Mohan Kumar wrote:
By default 9p.u is used, you can override by that
mount -t 9p
On Mon, Oct 15, 2012 at 6:36 AM, Chris Webb ch...@arachsys.com wrote:
Whilst we can mount the shares on each host and then use qemu's 9p
passthrough/proxy support to access the mountpoint, going via the host
kernel and vfs like this feels quite inefficient. We would be converting
back and
On Sun, Apr 24, 2011 at 2:31 PM, Rob Landley rland...@parallels.com wrote:
So on the host side I'm trying to do this:
$ qemu -cpu pentium3 -nographic -no-reboot -kernel bzImage \
-hda hda.sqf -append 'root=/dev/hda rw init=/sbin/init.sh panic=1 \
PATH=/bin:/sbin console=ttyS0 HOST=i686 '
