Re: File sharing over virtio-9p
On Mon, Oct 28, 2019 at 12:29:40 +0900, Ryota Ozaki wrote: > On Fri, Oct 25, 2019 at 11:19 PM Mouse wrote: > > > > > [W]hich of the following is more readable to the user: > > > > > $ ls foo > > > ls: foo: No such file or directory > > > > > or > > > > > $ ls foo > > > ls: stat(foo): No such file or directory > > > > It depends entirely on the user. > > > > As I recently wrote on a non-NetBSD mailing list, there is no such > > thing as a good or bad user interface; there is only a good or bad user > > interfaces for a particular user (or class of sufficiently-similar > > users). > > > > I've lost track of the number of times I've had to resort to a > > sledgehammer such as ktrace to find out what's really going wrong > > because an error message doesn't report enough information. > > I've had similar experiences on KASSERT; if a KASSERT fails because of > memory corruption, I wish to know not only if it fails or not but also > values used in KASSERT. KASSERT is, very specifically, information for developers (asserting something about the internal state of the code), not for users. -uwe
Re: File sharing over virtio-9p
On Fri, Oct 25, 2019 at 11:19 PM Mouse wrote: > > > [W]hich of the following is more readable to the user: > > > $ ls foo > > ls: foo: No such file or directory > > > or > > > $ ls foo > > ls: stat(foo): No such file or directory > > It depends entirely on the user. > > As I recently wrote on a non-NetBSD mailing list, there is no such > thing as a good or bad user interface; there is only a good or bad user > interfaces for a particular user (or class of sufficiently-similar > users). > > I've lost track of the number of times I've had to resort to a > sledgehammer such as ktrace to find out what's really going wrong > because an error message doesn't report enough information. I've had similar experiences on KASSERT; if a KASSERT fails because of memory corruption, I wish to know not only if it fails or not but also values used in KASSERT. Anyway thank you for suggestions. I committed the patches with changing the error message for open while keeping one for setsockopt. It may be good to have guidelines on writing error messages somewhere. ozaki-r
Re: File sharing over virtio-9p
> [W]hich of the following is more readable to the user: > $ ls foo > ls: foo: No such file or directory > or > $ ls foo > ls: stat(foo): No such file or directory It depends entirely on the user. As I recently wrote on a non-NetBSD mailing list, there is no such thing as a good or bad user interface; there is only a good or bad user interfaces for a particular user (or class of sufficiently-similar users). I've lost track of the number of times I've had to resort to a sledgehammer such as ktrace to find out what's really going wrong because an error message doesn't report enough information. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: File sharing over virtio-9p
On Fri, Oct 25, 2019 at 3:04 PM Michael van Elst wrote: > > ozaki.ry...@gmail.com (Ryota Ozaki) writes: > > >> @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) > >> + err(1, "setsockopt(SO_NOSIGPIPE)"); > >> +err(1, "open(%s)", path); > > >I prefer more informative messages. Why do you want to trim them? > > > Usually the error gives enough context, e.g. SO_NOSIGPIPE is a socket option > and telling that it's setsockopt failing is redundant and printing > an input file name is enough when the error identifies the operation > or the specific operation doesn't matter. > > But there is no rule for this, in particular when embedding filenames > where multiple operations are possible. Many people seem to prefer even > more verbose phrases like "Cannot open `%s'". Our code base has lots > of variants. I think I'm affected by ping6 or something (it's just one of variants though). > > I personally would prefer error messages without special characters > so that you can grep them easily. :) Indeed. A type of annoying messages is that a phrase is separated into two (or more) lines to avoid the 80 character limit. That's quite anti-grep :-/ ozaki-r
Re: File sharing over virtio-9p
On Fri, Oct 25, 2019 at 2:38 PM Valery Ushakov wrote: > > On Fri, Oct 25, 2019 at 12:56:43 +0900, Ryota Ozaki wrote: > > > > @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) > > > [...] > > > + err(1, "setsockopt(SO_NOSIGPIPE)"); > > > > > > I'd just trim it down to "SO_NOSIGPIPE". > > > > > > +err(1, "open(%s)", path); > > > > > > Ditto. Just make it "%s". > > > > I prefer more informative messages. Why do you want to trim them? > > Consider that from the user perspective. As a developer it's tempting > to dump the implementation details, but which of the following is more > readable to the user: > > $ ls foo > ls: foo: No such file or directory > > or > > $ ls foo > ls: stat(foo): No such file or directory Hm, the example makes sense to me (so I'll fix open's one), but doesn't for setsockopt: mount_9p: SO_NOSIGPIPE: Cannot allocate memory or mount_9p: setsockopt(SO_NOSIGPIPE): Cannot allocate memory I think the latter looks readable/understandable to users. ozaki-r
Re: File sharing over virtio-9p
ozaki.ry...@gmail.com (Ryota Ozaki) writes: >> @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) >> + err(1, "setsockopt(SO_NOSIGPIPE)"); >> +err(1, "open(%s)", path); >I prefer more informative messages. Why do you want to trim them? Usually the error gives enough context, e.g. SO_NOSIGPIPE is a socket option and telling that it's setsockopt failing is redundant and printing an input file name is enough when the error identifies the operation or the specific operation doesn't matter. But there is no rule for this, in particular when embedding filenames where multiple operations are possible. Many people seem to prefer even more verbose phrases like "Cannot open `%s'". Our code base has lots of variants. I personally would prefer error messages without special characters so that you can grep them easily. :) -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: File sharing over virtio-9p
On Fri, Oct 25, 2019 at 12:56:43 +0900, Ryota Ozaki wrote: > > @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) > > [...] > > + err(1, "setsockopt(SO_NOSIGPIPE)"); > > > > I'd just trim it down to "SO_NOSIGPIPE". > > > > +err(1, "open(%s)", path); > > > > Ditto. Just make it "%s". > > I prefer more informative messages. Why do you want to trim them? Consider that from the user perspective. As a developer it's tempting to dump the implementation details, but which of the following is more readable to the user: $ ls foo ls: foo: No such file or directory or $ ls foo ls: stat(foo): No such file or directory -uwe
Re: File sharing over virtio-9p
On Thu, Oct 24, 2019 at 13:32:59 +0900, Ryota Ozaki wrote: > I've prepared complete patches ready to commit: > https://www.netbsd.org/~ozaki-r/tweak-MAKEDEV.diff > https://www.netbsd.org/~ozaki-r/vio9p.diff > https://www.netbsd.org/~ozaki-r/vio9p-configs.diff > https://www.netbsd.org/~ozaki-r/mount_9p-cdev.diff Just a few minor nit-picks: @@ -60,6 +60,8 @@ usage(void) [...] + fprintf(stderr, " %s [-s] [-o mntopts] -cu cdevfile mountpoint\n", Why not [-su] as in the usage just above for the TCP case? @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) [...] + err(1, "setsockopt(SO_NOSIGPIPE)"); I'd just trim it down to "SO_NOSIGPIPE". +err(1, "open(%s)", path); Ditto. Just make it "%s". Thanks! -uwe
Re: File sharing over virtio-9p
On Tue, May 21, 2019 at 1:39 PM Ryota Ozaki wrote: > > Hi, > > The following two patches enables a NetBSD guest running > on a Linux KVM to share files with its host over virtio-9p. > > https://www.netbsd.org/~ozaki-r/vio9p.diff > https://www.netbsd.org/~ozaki-r/mount_9p-cdev.diff > > The first patch exports a 9p endpoint of virtio-9p via a character > device (e.g., /dev/vio9p0) and the second one extends mount_9p > (puffs) to talk with a 9p server inside qemu via the character device. > > [Usage] > > Export a directory of a host via virtio-9p. The below XML is part of > a libvirt domain configuration. It exports "/var/lib/libvirt/export" > directory with a tag "test". If it is the first entry, it will have > minor number 0 and /dev/vio9p0 is assigned to it typically. > > > > >function='0x0'/> > > > A boot log of vio9p looks like this: > > virtio0 at pci0 dev 3 function 0 > virtio0: Virtio 9P Transport Device (rev. 0x00) > vio9p0 at virtio0: Features: 0x1000 > virtio0: allocated 12288 byte for virtqueue 0 for vio9p, size 128 > virtio0: using 4096 byte (256 entries) indirect descriptors > vio9p0: tagged as test > virtio0: interrupting at ioapic0 pin 11 > > A NetBSD guest can mount the exported directory with mount_9p. > > mount_9p -cu /dev/vio9p0 /mnt/9p > > -c tells mount_9p to interpret the first argument as a character > device file to talk with. > > > Have fun, > ozaki-r I've prepared complete patches ready to commit: https://www.netbsd.org/~ozaki-r/tweak-MAKEDEV.diff https://www.netbsd.org/~ozaki-r/vio9p.diff https://www.netbsd.org/~ozaki-r/vio9p-configs.diff https://www.netbsd.org/~ozaki-r/mount_9p-cdev.diff Any comments? I would like to commit them in several days if there is no objection. Regards, ozaki-r
Re: File sharing over virtio-9p
On Tue, 21 May 2019 at 03:28, Ryota Ozaki wrote: > > Hi, > > The following two patches enables a NetBSD guest running > on a Linux KVM to share files with its host over virtio-9p. > Have fun, > ozaki-r Thanks.
File sharing over virtio-9p
Hi, The following two patches enables a NetBSD guest running on a Linux KVM to share files with its host over virtio-9p. https://www.netbsd.org/~ozaki-r/vio9p.diff https://www.netbsd.org/~ozaki-r/mount_9p-cdev.diff The first patch exports a 9p endpoint of virtio-9p via a character device (e.g., /dev/vio9p0) and the second one extends mount_9p (puffs) to talk with a 9p server inside qemu via the character device. [Usage] Export a directory of a host via virtio-9p. The below XML is part of a libvirt domain configuration. It exports "/var/lib/libvirt/export" directory with a tag "test". If it is the first entry, it will have minor number 0 and /dev/vio9p0 is assigned to it typically. A boot log of vio9p looks like this: virtio0 at pci0 dev 3 function 0 virtio0: Virtio 9P Transport Device (rev. 0x00) vio9p0 at virtio0: Features: 0x1000 virtio0: allocated 12288 byte for virtqueue 0 for vio9p, size 128 virtio0: using 4096 byte (256 entries) indirect descriptors vio9p0: tagged as test virtio0: interrupting at ioapic0 pin 11 A NetBSD guest can mount the exported directory with mount_9p. mount_9p -cu /dev/vio9p0 /mnt/9p -c tells mount_9p to interpret the first argument as a character device file to talk with. Have fun, ozaki-r
