Re: Using the upcoming fsinfo()

From: L A Walsh <lkml@tlinx.org>
To: Ian Kent <raven@themaw.net>
Cc: Karel Zak <kzak@redhat.com>, util-linux@vger.kernel.org
Subject: Re: Using the upcoming fsinfo()
Date: Tue, 21 May 2019 12:21:09 -0700	[thread overview]
Message-ID: <5CE44FA5.9000700@tlinx.org> (raw)
In-Reply-To: <c6baaf226834e7238807fa469335c79eeadb4f34.camel@themaw.net>

On 2019/05/15 17:13, Ian Kent wrote:
> And, as I mentioned above, there's the needed ->fsinfo() super operation
> to cover the use of the existing ->show_options() operation (provided
> by pretty much all file systems) to get the file system specific options.
>
> So there's quite a bit of detail to be worked out for fsinfo() to be
> able to correctly provide all mount information.
>
> But, hey, that was the point of doing this now.
>   
----
	Maybe this is already planned behind the scenes, but I wanted to
throw out my own suggestion -- and that is to start with the new 
system call usage in its own cmdline tool that can be used just to call
or exercise the new call -- effectively allowing calling the new kernel call
from any shell based program -- allowing for a passthrough type operation.

	This serves to workout that the call always returns what you 
expect it to, familiarity with the new call and how it works as well as
developing a first interface to construct and parse calls-to and 
output-from the call.

	From there -- those first options could be moved to only 
be used with '--raw' or '--direct' switch with a new switch associated
with, perhaps another util that may eventually be replaced  with this
code that uses the new utility.

	All of that could be done along with a continuing build and
release of the older tools until such time as the new call-using
tool replaces all of the old tool to whatever standard is wanted.

	That way, it could allow not disturbing old code
while code is developed for using the new interface, allowing for
a seamless switch sometime later with the old progs being left around
for a release with some 'old' prefix and eventually not built by default
and moved to the project's "attic" later on.

	This can allow for an extended period of feedback & development
until all users are comfy w/the new tool (which might, in some cases,
have an option to generate the same output as the old tool (but using
the new call) for older scripts that might be less easy to update.

Anyway, just my general caution in code rewrites replacing old libs & utils.
And again, please forgive my saying something that may be self-evident,
standard procedure, or already planned, but just not detailed on list.

-linda