Re: Using the upcoming fsinfo()

[Ian Kent <raven@themaw.net>]

On Tue, 2019-05-21 at 12:21 -0700, L A Walsh wrote:
> 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.

I hadn't planned on producing a utility but I do have code that I've
been using to learn how to use the call.

I could turn that into a utility for use from scripts at some point.

> 
> 	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.

Avoiding having to parse string output (from the proc file system
mount tables) is one of the key reasons to use a system call for
this.

So this isn't the point of doing it.

The work for this (and some other new system calls) is being done
in the kernel so the issue isn't to work out what the system call
returns as much as it is to ensure the system call provides what's
needed, implement things that aren't yet done and work out ways of
providing things that are needed but can't yet be provided.

> 
> 	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.

I haven't looked at the tools at all.

It may be worth looking at them but fork and exec a program then
parse text output isn't usually the way these utilities should
work.

> 
> 	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.

The focus is on eliminating the need to read the proc file system
mount tables including getting the mount information for any single
mount.

When these tables are large and there's a fair bit of mount/umount
activity this can be a significant problem.

Getting this information usually means reading on average half of
the whole mount table every time and it's not possible to get info.
on a single mount without doing this.

Ian