Re: kern/59165: vio9p(4): expose tag through sysctl or device properties

["Ryota Ozaki via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/59165; it has been noted by GNATS.

From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
To: Christoph Badura <bad%bsd.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Tue, 25 Mar 2025 16:46:28 +0900

 I'm sorry for late reply...
 
 On Tue, Mar 18, 2025 at 8:27=E2=80=AFAM Christoph Badura <bad%bsd.de@localhost> wrote=
 :
 >
 > On Mon, Mar 17, 2025 at 05:33:44PM +0900, Ryota Ozaki wrote:
 > > On Tue, Mar 11, 2025 at 8:53=E2=80=AFPM Christoph Badura <bad%bsd.de@localhost> w=
 rote:
 > > > If you attach multiple virtio-9p file systems to the VM, does your pa=
 tch
 > > > create hw.vio9p0.tag, hw.vio9p1.tag etc.?
 > > Thank you for pointing this out. It assumed there was just one vio9p.
 >
 > I've been using at least two since last summer. :-)
 >
 > > I've put a fixed version:
 > > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v2.patch
 >
 > I guess the change from the previsous version is the use of
 > device_xname(self) in:
 > +           device_xname(self), SYSCTL_DESCR("VirtIO 9p status"),
 >
 > That all looks fine to me.
 
 Thanks.
 
 >
 > There is one more thing to think about: discoverability.
 > How do we find out which hw.vio9pN sysctl nodes exist?
 >
 > Of course, we can do "sysctl hw | grep \^hw.vio9p" and process that.
 > But that seems not right to me.
 > We should have something like hw.disknames for vio9p.
 > Maybe hw.vio9p.instances with a list of the instance names as strings?
 >
 > That shouldn't prevent you from committing your change
 >
 > Actually, I wish used a better MIB design in sysctl.
 > Like:
 >   hw.vio9p.instances =3D vio9p0 vio9p1
 >   hw.vio9p.vio9p0.tag =3D tag1
 >   hw.vio9p.vio9p1.tag =3D tag2
 >
 > And likewise:
 >   hw.vm.wm0.*
 >   hw.vm.wm1.*
 > etc.
 >
 > And a way for sysctl to just enumerate the immediate children of a node
 > Like:
 >   $ sysctl --enumerate-children hw.wm
 >   hw.wm.wm0
 >   hw.wm.wm1
 >   $
 
 That reminds me of a RESTful API that requires listing up available endpoin=
 ts.
 I agree with the demand for discoverability, but in this case (sysctl
 MIBs) I don't
 desire it so much because, as you said, we can know the existing of sysctl =
 MIBs
 by using grep, etc. The proposed MIB design may help to make scripts simple=
 ,
 but I'm not sure if it's essential for everyone.
 
 >
 > But we don't have that.  We could make a start with the hw.vio9p sub-MIB,
 > though.
 >
 > But perhaps this should be discussed on tech-kern.
 
 I agree.
 
   ozaki-r