Re: wedge device to name

2019-09-22 Thread Kamil Rytarowski 
On 22.09.2019 18:22, Christos Zoulas wrote:
> On Sep 22,  5:58pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: wedge device to name
> 
> | I understand and I know. Unfortunately (or fortunately) we will need to
> | live with the old syscall forever.
> 
> Yes, but cleaning the old code is obvious and simple. Untangling the
> sysctl-augmented API mess is nearly impossible.
> 

Looking at the diff here, just adding f_mntfromlabel[] is a better
choice and it does not make too much dead code in old syscall version.

I propose to go for versioning here.

> | A programmer friendly wrapper of sysctl could be implemented in libutil.
> 
> That is not really needed for the userland part; there is sysctlybyname();
> 
> Here's the actual change compared to ~100s of lines of sysctl code:
> 
> Index: kern/vfs_subr.c
> ===
> RCS file: /cvsroot/src/sys/kern/vfs_subr.c,v
> retrieving revision 1.471
> diff -u -u -r1.471 vfs_subr.c
> --- kern/vfs_subr.c   1 Jan 2019 10:06:54 -   1.471
> +++ kern/vfs_subr.c   22 Sep 2019 16:17:49 -
> @@ -1198,6 +1198,8 @@
>   sizeof(sbp->f_mntonname));
>   (void)memcpy(sbp->f_mntfromname, mp->mnt_stat.f_mntfromname,
>   sizeof(sbp->f_mntfromname));
> + (void)memcpy(sbp->f_mntfromlabel, mp->mnt_stat.f_mntfromlabel,
> + sizeof(sbp->f_mntfromlabel));
>   sbp->f_namemax = mbp->f_namemax;
>  }
>  
> Index: sys/statvfs.h
> ===
> RCS file: /cvsroot/src/sys/sys/statvfs.h,v
> retrieving revision 1.18
> diff -u -b -w -u -r1.18 statvfs.h
> --- sys/statvfs.h 5 Apr 2013 17:34:27 -   1.18
> +++ sys/statvfs.h 22 Sep 2019 16:18:43 -
> @@ -96,6 +96,7 @@
>   charf_fstypename[_VFS_NAMELEN]; /* fs type name */
>   charf_mntonname[_VFS_MNAMELEN];  /* directory on which mounted */
>   charf_mntfromname[_VFS_MNAMELEN];  /* mounted file system */
> + charf_mntfromlabel[_VFS_MNAMELEN];  /* disk label name if available 
> */
>  
>  };
>  
> Index: miscfs/specfs/spec_vnops.c
> ===
> RCS file: /cvsroot/src/sys/miscfs/specfs/spec_vnops.c,v
> retrieving revision 1.175
> diff -u -r1.175 spec_vnops.c
> --- miscfs/specfs/spec_vnops.c3 Sep 2018 16:29:35 -   1.175
> +++ miscfs/specfs/spec_vnops.c22 Sep 2019 16:19:53 -
> @@ -75,6 +75,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -366,10 +367,19 @@
>  void
>  spec_node_setmountedfs(vnode_t *devvp, struct mount *mp)
>  {
> + struct dkwedge_info dkw;
>  
>   KASSERT(devvp->v_type == VBLK);
>   KASSERT(devvp->v_specnode->sn_dev->sd_mountpoint == NULL || mp == NULL);
>   devvp->v_specnode->sn_dev->sd_mountpoint = mp;
> + if (mp == NULL)
> + return;
> +
> + if (bdev_ioctl(devvp->v_rdev, DIOCGWEDGEINFO, , FREAD, curlwp) != 0)
> + return;
> +
> + strlcpy(mp->mnt_stat.f_mntfromlabel, dkw.dkw_wname,
> + sizeof(mp->mnt_stat.f_mntfromlabel));
>  }
>  
>  /*
> 
> And I do understand how much code is needed for compat:
> 
> Legend:
> 
> + required change
> - autogenerated file
> 
> The rest are because of compat and glue.
> 
> christos
> 
> + M bin/df/df.c
>   M lib/libc/shlib_version
>   M lib/libc/compat/gen/Makefile.inc
>   A lib/libc/compat/gen/compat___getmntinfo13.c
>   M lib/libc/compat/gen/compat_opendir.c
>   M lib/libc/compat/sys/Makefile.inc
>   A lib/libc/compat/sys/compat___fhstatvfs140.c
>   A lib/libc/compat/sys/compat___fhstatvfs40.c
>   M lib/libc/compat/sys/compat_fhstatvfs.c
>   M lib/libc/compat/sys/compat_fhstatvfs1.c
>   M lib/libc/compat/sys/compat_statfs.c
>   A lib/libc/compat/sys/compat_statvfs.c
>   M lib/libc/include/namespace.h
>   M lib/libc/sys/Makefile.inc
>   M lib/libc/sys/statvfs.c
>   A sys/compat/common/compat_90_mod.c
>   M sys/compat/common/compat_mod.h
>   M sys/compat/common/files.common
>   M sys/compat/common/vfs_syscalls_20.c
>   M sys/compat/common/vfs_syscalls_30.c
>   A sys/compat/common/vfs_syscalls_90.c
>   M sys/compat/netbsd32/files.netbsd32
>   M sys/compat/netbsd32/netbsd32.h
>   A sys/compat/netbsd32/netbsd32_compat_90.c
>   M sys/compat/netbsd32/netbsd32_conv.h
>   M sys/compat/netbsd32/netbsd32_fs.c
> - M sys/compat/netbsd32/netbsd32_syscall.h
> - M sys/compat/netbsd32/netbsd32_syscallargs.h
> - M sys/compat/netbsd32/netbsd32_syscalls.c
> - M sys/compat/netbsd32/

Re: wedge device to name

2019-09-22 Thread Christos Zoulas 
On Sep 22,  5:58pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: wedge device to name

| I understand and I know. Unfortunately (or fortunately) we will need to
| live with the old syscall forever.

Yes, but cleaning the old code is obvious and simple. Untangling the
sysctl-augmented API mess is nearly impossible.

| A programmer friendly wrapper of sysctl could be implemented in libutil.

That is not really needed for the userland part; there is sysctlybyname();

Here's the actual change compared to ~100s of lines of sysctl code:

Index: kern/vfs_subr.c
===
RCS file: /cvsroot/src/sys/kern/vfs_subr.c,v
retrieving revision 1.471
diff -u -u -r1.471 vfs_subr.c
--- kern/vfs_subr.c 1 Jan 2019 10:06:54 -   1.471
+++ kern/vfs_subr.c 22 Sep 2019 16:17:49 -
@@ -1198,6 +1198,8 @@
sizeof(sbp->f_mntonname));
(void)memcpy(sbp->f_mntfromname, mp->mnt_stat.f_mntfromname,
sizeof(sbp->f_mntfromname));
+   (void)memcpy(sbp->f_mntfromlabel, mp->mnt_stat.f_mntfromlabel,
+   sizeof(sbp->f_mntfromlabel));
sbp->f_namemax = mbp->f_namemax;
 }
 
Index: sys/statvfs.h
===
RCS file: /cvsroot/src/sys/sys/statvfs.h,v
retrieving revision 1.18
diff -u -b -w -u -r1.18 statvfs.h
--- sys/statvfs.h   5 Apr 2013 17:34:27 -   1.18
+++ sys/statvfs.h   22 Sep 2019 16:18:43 -
@@ -96,6 +96,7 @@
charf_fstypename[_VFS_NAMELEN]; /* fs type name */
charf_mntonname[_VFS_MNAMELEN];  /* directory on which mounted */
charf_mntfromname[_VFS_MNAMELEN];  /* mounted file system */
+   charf_mntfromlabel[_VFS_MNAMELEN];  /* disk label name if available 
*/
 
 };
 
Index: miscfs/specfs/spec_vnops.c
===
RCS file: /cvsroot/src/sys/miscfs/specfs/spec_vnops.c,v
retrieving revision 1.175
diff -u -r1.175 spec_vnops.c
--- miscfs/specfs/spec_vnops.c  3 Sep 2018 16:29:35 -   1.175
+++ miscfs/specfs/spec_vnops.c  22 Sep 2019 16:19:53 -
@@ -75,6 +75,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -366,10 +367,19 @@
 void
 spec_node_setmountedfs(vnode_t *devvp, struct mount *mp)
 {
+   struct dkwedge_info dkw;
 
KASSERT(devvp->v_type == VBLK);
KASSERT(devvp->v_specnode->sn_dev->sd_mountpoint == NULL || mp == NULL);
devvp->v_specnode->sn_dev->sd_mountpoint = mp;
+   if (mp == NULL)
+   return;
+
+   if (bdev_ioctl(devvp->v_rdev, DIOCGWEDGEINFO, , FREAD, curlwp) != 0)
+   return;
+
+   strlcpy(mp->mnt_stat.f_mntfromlabel, dkw.dkw_wname,
+   sizeof(mp->mnt_stat.f_mntfromlabel));
 }
 
 /*

And I do understand how much code is needed for compat:

Legend:

+ required change
- autogenerated file

The rest are because of compat and glue.

christos

+ M bin/df/df.c
  M lib/libc/shlib_version
  M lib/libc/compat/gen/Makefile.inc
  A lib/libc/compat/gen/compat___getmntinfo13.c
  M lib/libc/compat/gen/compat_opendir.c
  M lib/libc/compat/sys/Makefile.inc
  A lib/libc/compat/sys/compat___fhstatvfs140.c
  A lib/libc/compat/sys/compat___fhstatvfs40.c
  M lib/libc/compat/sys/compat_fhstatvfs.c
  M lib/libc/compat/sys/compat_fhstatvfs1.c
  M lib/libc/compat/sys/compat_statfs.c
  A lib/libc/compat/sys/compat_statvfs.c
  M lib/libc/include/namespace.h
  M lib/libc/sys/Makefile.inc
  M lib/libc/sys/statvfs.c
  A sys/compat/common/compat_90_mod.c
  M sys/compat/common/compat_mod.h
  M sys/compat/common/files.common
  M sys/compat/common/vfs_syscalls_20.c
  M sys/compat/common/vfs_syscalls_30.c
  A sys/compat/common/vfs_syscalls_90.c
  M sys/compat/netbsd32/files.netbsd32
  M sys/compat/netbsd32/netbsd32.h
  A sys/compat/netbsd32/netbsd32_compat_90.c
  M sys/compat/netbsd32/netbsd32_conv.h
  M sys/compat/netbsd32/netbsd32_fs.c
- M sys/compat/netbsd32/netbsd32_syscall.h
- M sys/compat/netbsd32/netbsd32_syscallargs.h
- M sys/compat/netbsd32/netbsd32_syscalls.c
- M sys/compat/netbsd32/netbsd32_syscalls_autoload.c
- M sys/compat/netbsd32/netbsd32_sysent.c
- M sys/compat/netbsd32/netbsd32_systrace_args.c
  M sys/compat/netbsd32/syscalls.conf
  M sys/compat/netbsd32/syscalls.master
  A sys/conf/compat_netbsd90.config
  M sys/conf/files
- M sys/kern/init_sysent.c
- M sys/kern/syscalls.c
- M sys/kern/syscalls.conf
- M sys/kern/syscalls.master
- M sys/kern/syscalls_autoload.c
- M sys/kern/systrace_args.c
+ M sys/kern/vfs_subr.c
- M sys/kern/vfs_syscalls.c
+ M sys/miscfs/specfs/spec_vnops.c
  M sys/modules/Makefile
  A sys/modules/compat_90/Makefile
  A sys/modules/compat_netbsd32_90/Makefile
- M sys/rump/rump.sysmap
- M sys/rump/include/rump/rump_syscalls.h
- M sys/rump/librump/rumpkern/rump_syscalls.c
- M sys/rump/librump/rumpkern/rumpkern_syscalls.c
- M sys/rump/librump/rumpnet/rumpnet_sysca

Re: wedge device to name

2019-09-22 Thread Kamil Rytarowski 
On 22.09.2019 17:50, Christos Zoulas wrote:
> Yes, but bolting on extra functionality that belongs to syscalls using
> sysctl creates a rats
> nest for userland in the long term, and it is not exactly cheap to
> maintain and document 
> all the sysctl code. And with versioning you get to kill the old
> versions if you want, with
> sysctl you are left with the mess.
> 
> christos
> 
>> On Sep 22, 2019, at 11:42 AM, Kamil Rytarowski > > wrote:
>>
>> ,
> 

I understand and I know. Unfortunately (or fortunately) we will need to
live with the old syscall forever.

A programmer friendly wrapper of sysctl could be implemented in libutil.



signature.asc
Description: OpenPGP digital signature

Re: wedge device to name

2019-09-22 Thread Christos Zoulas 
Well, it is less natural and the programs need to so something special to get 
the information.
Anyway if people prefer the sysctl patch we can do that instead. OTOH it is 
very instructive
to see how much work is needed to version a syscall in a single commit :-)

christos

> On Sep 22, 2019, at 10:55 AM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 22.09.2019 15:39, Christos Zoulas wrote:
>> In article ,
>> Christos Zoulas  wrote:
>>> In article ,
>>> Michael van Elst  wrote:
 chris...@astron.com (Christos Zoulas) writes:
 
> I added that to df, but it needs root/operator in order to access the
> device node to get wedge info. I also wrote a patch to expose the
> wedge info via sysctl:
 
 Alternatives ?
 
 Expose via an enhanced statvfs() syscall. After all df is a user interface
 for that syscall. It would at least allow in theory to return a copy
 of the exact mount path.
>>> 
>>> Yes, this is the first thing I thought. I will see how feasible it it.
>> 
>> I've implemented this but the patch is fairly long (due to the 4 syscalls
>> that need to be versioned). Anyway it works, and once I get a successful
>> build I will post the pstch here.
>> 
>> christos
>> 
> 
> What's wrong with sysctl?
> 
> It works nicely and this use-case is not performance sensitive.
> 
> 
>

Re: wedge device to name

2019-09-22 Thread Christos Zoulas 
In article ,
Christos Zoulas  wrote:
>In article ,
>Michael van Elst  wrote:
>>chris...@astron.com (Christos Zoulas) writes:
>>
>>>I added that to df, but it needs root/operator in order to access the
>>>device node to get wedge info. I also wrote a patch to expose the
>>>wedge info via sysctl:
>>
>>Alternatives ?
>>
>>Expose via an enhanced statvfs() syscall. After all df is a user interface
>>for that syscall. It would at least allow in theory to return a copy
>>of the exact mount path.
>
>Yes, this is the first thing I thought. I will see how feasible it it.

I've implemented this but the patch is fairly long (due to the 4 syscalls
that need to be versioned). Anyway it works, and once I get a successful
build I will post the pstch here.

christos

Re: wedge device to name

2019-09-19 Thread Christos Zoulas 
In article ,
Michael van Elst  wrote:
>chris...@astron.com (Christos Zoulas) writes:
>
>>I added that to df, but it needs root/operator in order to access the
>>device node to get wedge info. I also wrote a patch to expose the
>>wedge info via sysctl:
>
>Alternatives ?
>
>Expose via an enhanced statvfs() syscall. After all df is a user interface
>for that syscall. It would at least allow in theory to return a copy
>of the exact mount path.

Yes, this is the first thing I thought. I will see how feasible it it.

>Use drvctl(4) to expose such data. XML haters won't like it, but
>we already use it to get driver details and future enhancements would
>be trivial.

Yes, the xml issue is a barrier to entry :-)

>Either could be hidden in getvfsstat() with a special flag, so
>details don't have to be spread over client programs.

Ok.

christos

Re: wedge device to name

2019-09-19 Thread Emmanuel Dreyfus 
On Thu, Sep 19, 2019 at 02:51:12AM -, Christos Zoulas wrote:
> But I am not sure if I should commit it... Here it is... Should I?

I vote for it (and mount, raidctl, whatever...)

-- 
Emmanuel Dreyfus
m...@netbsd.org

Re: wedge device to name

2019-09-19 Thread Michael van Elst 
chris...@astron.com (Christos Zoulas) writes:

>I added that to df, but it needs root/operator in order to access the
>device node to get wedge info. I also wrote a patch to expose the
>wedge info via sysctl:

Alternatives ?

Expose via an enhanced statvfs() syscall. After all df is a user interface
for that syscall. It would at least allow in theory to return a copy
of the exact mount path.

Use drvctl(4) to expose such data. XML haters won't like it, but
we already use it to get driver details and future enhancements would
be trivial.

Either could be hidden in getvfsstat() with a special flag, so
details don't have to be spread over client programs.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: wedge device to name

2019-09-18 Thread Christos Zoulas 
In article ,
Michael van Elst  wrote:
>m...@netbsd.org (Emmanuel Dreyfus) writes:
>
>>But since almost all commands do the NAME=label to /dev/device translation,
>>you can take NAME=label as a device path.
>
>Only some NetBSD commands do. Most are old-fashioned and want file paths
>to deal with, and that's where the current mount output may come handy.
>
>There's nothing against an option making mount or df print wedge names
>and people can just use aliases in their profile.

I added that to df, but it needs root/operator in order to access the
device node to get wedge info. I also wrote a patch to expose the
wedge info via sysctl:

$ sysctl -a | grep dkw
hw.dkwedge.dk0.wname = wd0a
hw.dkwedge.dk0.parent = wd0
hw.dkwedge.dk0.ptype = ffs
hw.dkwedge.dk0.size = 201326529
hw.dkwedge.dk0.offset = 63
hw.dkwedge.dk1.wname = wd0b
hw.dkwedge.dk1.parent = wd0
hw.dkwedge.dk1.ptype = swap
hw.dkwedge.dk1.size = 8388608
hw.dkwedge.dk1.offset = 201326592

But I am not sure if I should commit it... Here it is... Should I?

christos

Index: df/df.c
===
RCS file: /cvsroot/src/bin/df/df.c,v
retrieving revision 1.94
diff -u -p -u -r1.94 df.c
--- df/df.c 18 Sep 2019 20:14:44 -  1.94
+++ df/df.c 19 Sep 2019 02:49:43 -
@@ -54,6 +54,7 @@ __RCSID("$NetBSD: df.c,v 1.94 2019/09/18
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -310,8 +311,12 @@ getwedgeinfo(const struct statvfs *mntbu
}
rdn++;
int fd = opendisk(rdn, O_RDONLY, buf, sizeof(buf), false);
-   if (fd == -1)
-   err(EXIT_FAILURE, "opendisk on `%s' failed", rdn);
+   if (fd == -1) {
+   size_t oldlen = sizeof(wi[i].dkw_wname);
+   snprintf(buf, sizeof(buf), "hw.dkwedge.%s.wname", rdn);
+   sysctlbyname(buf, wi[i].dkw_wname, , NULL, 0);
+   continue;
+   }
if (ioctl(fd, DIOCGWEDGEINFO, [i]) == -1) {
warn("DIOCGWEDGEINFO for `%s' failed", buf);
}
Index: dk.c
===
RCS file: /cvsroot/src/sys/dev/dkwedge/dk.c,v
retrieving revision 1.97
diff -u -p -u -r1.97 dk.c
--- dk.c12 May 2018 10:33:06 -  1.97
+++ dk.c19 Sep 2019 02:50:02 -
@@ -43,6 +43,7 @@ __KERNEL_RCSID(0, "$NetBSD: dk.c,v 1.97 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -90,6 +91,7 @@ struct dkwedge_softc {
kcondvar_t  sc_dkdrn;
u_int   sc_iopend;  /* I/Os pending */
int sc_flags;   /* flags (sc_iolock) */
+   struct sysctllog *sc_sysctllog; /* sysctl info */
 };
 
 #defineDK_F_WAIT_DRAIN 0x0001  /* waiting for I/O to drain */
@@ -107,6 +109,9 @@ static int  dkwedge_del1(struct dkwedge_i
 static int dk_open_parent(dev_t, int, struct vnode **);
 static int dk_close_parent(struct vnode *, int);
 
+static voiddkwedge_sysctl_attach(struct dkwedge_softc *);
+static voiddkwedge_sysctl_detach(struct dkwedge_softc *);
+
 static dev_type_open(dkopen);
 static dev_type_close(dkclose);
 static dev_type_read(dkread);
@@ -483,6 +488,8 @@ dkwedge_add(struct dkwedge_info *dkw)
sc->sc_size, sc->sc_offset,
sc->sc_ptype[0] == '\0' ? "" : sc->sc_ptype);
 
+   dkwedge_sysctl_attach(sc);
+
return (0);
 }
 
@@ -545,6 +552,8 @@ dkwedge_del1(struct dkwedge_info *dkw, i
if ((sc = dkwedge_find(dkw, NULL)) == NULL)
return (ESRCH);
 
+   dkwedge_sysctl_detach(sc);
+
return config_detach(sc->sc_dev, flags);
 }
 
@@ -1684,3 +1693,68 @@ dkwedge_get_parent_name(dev_t dev)
return sc->sc_parent->dk_name;
 }
 
+static void
+dkwedge_sysctl_detach(struct dkwedge_softc *sc)
+{
+   sysctl_teardown(>sc_sysctllog);
+}
+
+static void
+dkwedge_sysctl_attach(struct dkwedge_softc *sc)
+{
+   int rc;
+   static const struct sysctlnode *rnode;
+   static struct sysctllog *dlog;
+   const struct sysctlnode *dnode;
+
+   struct sysctllog **clog = >sc_sysctllog;
+
+   if (rnode == NULL) {
+   if ((rc = sysctl_createv(, 0, NULL, ,
+   CTLFLAG_PERMANENT, CTLTYPE_NODE, "dkwedge",
+   SYSCTL_DESCR("wedge root"),
+   NULL, 0, NULL, 0, CTL_HW, CTL_CREATE, CTL_EOL)) != 0)
+   goto err;
+   }
+
+   if ((rc = sysctl_createv(clog, 0, , ,
+   CTLFLAG_READONLY, CTLTYPE_NODE, device_xname(sc->sc_dev),
+   SYSCTL_DESCR("wedge info"),
+   NULL, 0, NULL, 0, CTL_CREATE, CTL_EOL)) != 0)
+   goto err;
+
+   if ((rc = sysctl_createv(clog, 0, , NULL,
+   CTLFLAG_READONLY, CTLTYPE_STRING, "wname",
+   SYSCTL_DESCR("wedge name"),
+   NULL, 0, sc->sc_wname, 0, CTL_CREATE,

Re: wedge device to name

2019-09-18 Thread Michael van Elst 
On Wed, Sep 18, 2019 at 01:24:24PM -0700, John Nemeth wrote:

>  We just need the device path to be the name, which it already
> is for LVMs.  This is something that a devfs could do easily.  :->
> More seriously, I do believe that a devfs would be a good thing.

Ah, a can of worms, open too. :)

Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: wedge device to name

2019-09-18 Thread John Nemeth 
On Sep 18,  2:57pm, Michael van Elst wrote:
} 
} >Is there a reason why we do not translate wedges devices to their name?
} >I mean, df and mount report about /dev/dkN, which is not very helpful
} >since it can change quickly. Reporting about NAME= seems a better idea.
} 
} >In order to do it, we need a reverse getfsspecname(), and use it everywhere
} >reasonable: df mount swapctl raidctl ... other ideas?
} 
} It's not necessarily a good idea to hide the dk devices, so that probably
} needs to be an optional output. Also because there are people parsing
} such output and expect a device path.

 We just need the device path to be the name, which it already
is for LVMs.  This is something that a devfs could do easily.  :->
More seriously, I do believe that a devfs would be a good thing.

}-- End of excerpt from Michael van Elst

Re: wedge device to name

2019-09-18 Thread Michael van Elst 
m...@netbsd.org (Emmanuel Dreyfus) writes:

>But since almost all commands do the NAME=label to /dev/device translation,
>you can take NAME=label as a device path.

Only some NetBSD commands do. Most are old-fashioned and want file paths
to deal with, and that's where the current mount output may come handy.

There's nothing against an option making mount or df print wedge names
and people can just use aliases in their profile.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: wedge device to name

2019-09-18 Thread Emmanuel Dreyfus 
On Wed, Sep 18, 2019 at 02:57:39PM -, Michael van Elst wrote:
> It's not necessarily a good idea to hide the dk devices, so that probably
> needs to be an optional output. Also because there are people parsing
> such output and expect a device path.

But since almost all commands do the NAME=label to /dev/device translation,
you can take NAME=label as a device path.

On the other hand, it is really annoying that /etc/fstab and mount
show so different outputs.


-- 
Emmanuel Dreyfus
m...@netbsd.org

Re: wedge device to name

2019-09-18 Thread Michael van Elst 
m...@netbsd.org (Emmanuel Dreyfus) writes:

>Hello

>Is there a reason why we do not translate wedges devices to their name?
>I mean, df and mount report about /dev/dkN, which is not very helpful
>since it can change quickly. Reporting about NAME= seems a better idea.

>In order to do it, we need a reverse getfsspecname(), and use it everywhere
>reasonable: df mount swapctl raidctl ... other ideas?

It's not necessarily a good idea to hide the dk devices, so that probably
needs to be an optional output. Also because there are people parsing
such output and expect a device path.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

wedge device to name

2019-09-18 Thread Emmanuel Dreyfus 
Hello

Is there a reason why we do not translate wedges devices to their name?
I mean, df and mount report about /dev/dkN, which is not very helpful
since it can change quickly. Reporting about NAME= seems a better idea.

In order to do it, we need a reverse getfsspecname(), and use it everywhere
reasonable: df mount swapctl raidctl ... other ideas?

Any idea for the reverse getfsspecname() name?

-- 
Emmanuel Dreyfus
m...@netbsd.org