On 2019/05/21 19:59, Ian Kent wrote:
> 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.
>
---
not required, but thought it might allow for more types of
tests/usages.
If it is really of limited or no benefit, I'm not gonna lose sleep.
> 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.
>
I get that....this wasn't intended as an 'endpoint' just a way for those
not
implementing and using the calls to get a feel for the call. It may
not serve
a useful purpose in this case, but some system calls have direct
user-utils that
are very useful. The lack of a system util to manipulate the pty calls
forced
me to write a few-line 'C' prog just to make 1 call to approve
something. Eventually switched to a more robust interface in perl.
> 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.
>
----
No basic testing that the kernel call is producing exactly what you are
expecting is needed, I take it.
>
>> 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 wasn't what I meant -- just that if you implement functionality in
a test prog, eventually you would be able to library-ize the call for other
purposes. I got the impression th
> 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.
>
----
That sounds like a deficiency in the way mount tables are displayed.
Just like you can look at all net-io with a device name in column 0,
there's another directory where each device is a filename entry and by
looking at that
you can just look at the stats of that 1 file.
Block devices have the same type of all-or-single readouts as well.
So why not mounts?
I.e. why not subdirs for 'by-mountpoint', or by-device, or
whole-dev-vs.partition, or by UUID....like some things are listed
in /dev. That would allow you to narrow in on the mount you want for
doing whatever.
The advantage of putting it in proc is that everyone easily benefits in a
portable, and easy to read interface, where-as binary-interfaces are what
make windows windows, with text interfaces on linux allowing for easy
prototyping and creative usages.
Just this one part -- of wanting a kernel call just to narrow scope
seems like a
perfect reason to add different ways of addressing mounts by different
keywords.
> Ian
>
>
