bin/55355: mount on symlinked device spits undesired warning

[greywolf%starwolf.com@localhost]

>Number:         55355
>Category:       bin
>Synopsis:       implement a way to turn off the warning from mount(8) & co.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 07 04:55:00 +0000 2020
>Originator:     The Grey Wolf
>Release:        NetBSD 9.99.63
>Organization:
Star Wolf Innovations
>Environment:
System: NetBSD eddie.starwolf.com 9.99.63 NetBSD 9.99.63 (GENERIC) #1: Thu May 28 01:02:22 PDT 2020 greywolf%eddie.starwolf.com@localhost:/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	Hi, I know this seems silly, and will probably get rejected, but...

	When mounting an LVM, I usually prefer to use /dev/VGname/LVname vs.
	the (usually longer) /dev/mapper/VGname-LVname.  Mounting on that 
	device, because it is a symlink, produces the warning:

	"/dev/VGname/LVname" is a relative/non-resolved path; using
	"/dev/mapper/VGname-LVname" instead.

	Whilst I understand the intent, it is bothersome, and I would like
	some way to turn it off (as it is, I am currently "#if
	0/#endif"ing around the warnx() statement in sbin/mount/pathadj.c.
	I don't like this, though, for the same reason that I don't want
	to bitbucket the output from mount in case something goes wrong

	The only way I see to handle this, because pathadj() performs both
	the adjustment and the warning, is to add a 'nowarn' variable to
	pathadj(), corresponding code inside of pathadj(), plus options
	and associated variables to everything that uses pathadj(), so
	a fix based on this seems highly unlikely.  Having a warning message
	on a mount referencing a valid symlink feels absurd on its face,
	though.  I can see complaining, of course, should the end target
	not resolve.

	I could point to lvm itself and say it's a problem, but NetBSD
	(I am guessing) doesn't actually maintain the code except insomuch
	as to get it to build and operate under NetBSD.

	In any case, the warning is silly, in my opinion, for a path that
	resolves.  It's not something I feel the need to know.

>How-To-Repeat:
	lvcreate -L size -n LVname VGname
	newfs /dev/VGname/LVname (which references, properly, rLVname)
	mount /dev/VGname/LVname /mnt

>Fix:
	If a dowarn or silent parameter added to 
		/sbin/mount/pathadj.c/pathadj()
	would be acceptable, I will gladly submit the requisite patches.