The "mount" function versus the "mount" command

In the "mount" function (http://man7.org/linux/man-pages/man2/mount.2.html), as I understand it, the programmer is required to pass a non-empty C-string for the filesystem type as the third parameter. Yet in the "mount" command (http://man7.org/linux/man-pages/man8/mount.8.html) it is optional whether or not the '-t fstype' is passed to the command.

Why design a function call which requires the programmer to figure out the filesystem type, whereas the equivalent command does not require it ?

I used libblkid to pick up the filesystem type to pass to the "mount" function successfully in my code, but I do not understand why the "mount" function could not have been designed so that when a null pointer is passed as the 3rd parameter it acts like the "mount" command and figures out the filesystem type to use itself.

Well, mount(8) program does more than just calling mount(2) system-call, for example:

If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems. All of the filesystem types listed there will be tried, except for those that are labeled "nodev" (e.g., devpts, proc and nfs). If /etc/filesystems ends in a line with a single *, mount will read /proc/filesystems afterwards. While trying, all filesystem types will be mounted with the mount option silent.

Originally Posted by NevemTeve Well, mount(8) program does more than just calling mount(2) system-call, for example:

I thought that was what I said. But why was not the 'mount' function designed in the same way as the 'mount' command if a null ptr is passed as the 3rd parameter to the 'mount' function ?

As NevemTeve said, they are designed for different uses:

mount(8) program does more than just calling mount(2) system-call...

The better question would be, "What were the criteria for implementing the mount() function?", and a similar question for the mount program.

An even better question might be, "Why should one expect the mount() library function to work like the mount program?". They are different animals, produced by different people at different times for different reasons. Only the name is the same.

Why do you expect them to work the same?

If the developers of the mount program had chosen a different name, fsmnt for example, would you have asked, "Why does fsmnt handle args differently than mount()"?

Well, it is common that a system-call does simpler things than a utility-program. I think OP wishes for a 'libmount' component. Which does exist.

Originally Posted by astrogeek As NevemTeve said, they are designed for different uses: The better question would be, "What were the criteria for implementing the mount() function?", and a similar question for the mount program. An even better question might be, "Why should one expect the mount() library function to work like the mount program?". They are different animals, produced by different people at different times for different reasons. Only the name is the same. Why do you expect them to work the same? If the developers of the mount program had chosen a different name, fsmnt for example, would you have asked, "Why does fsmnt handle args differently than mount()"?

I expect them to work the same because the purpose of both is the same. I guess it was foolish to even bring this up, even if it is an anomaly in Linux. The answer I am always given is, essentially, "it is what it is", meaning "it may be foolish that they work different but nobody is going to do anything about it." Clearly the "mount" function could work just like the "mount" command, but this would make things much easier for programmers and we don't want to do that, do we ?

Originally Posted by NevemTeve Well, it is common that a system-call does simpler things than a utility-program. I think OP wishes for a 'libmount' component. Which does exist.

There is no inherent reason why a function call should be simpler or more complex than an operating system command.

Originally Posted by eldiener There is no inherent reason why a function call should be simpler or more complex than an operating system command.

hm. Why do you think that? Where is it coming from?
There is no [inherent] reason to make a function call identical to a command. Isn't there?

Also there might be a reason why I keep repeating the term system call
https://en.wikipedia.org/wiki/System_call

Originally Posted by eldiener I thought that was what I said. But why was not the 'mount' function designed in the same way as the 'mount' command if a null ptr is passed as the 3rd parameter to the 'mount' function ?

The system call does not impose policy...

In this case, that is the job of the application. It can make any type of decisions it wants to decide what to do.

Burying that in the system call would make it very difficult to change the policy. That was one of the reasons for the /etc/filesystems file - it specifies how the application is to respond. If missing then the application looks elsewhere.

Originally Posted by eldiener I expect them to work the same because the purpose of both is the same. I guess it was foolish to even bring this up, even if it is an anomaly in Linux.

It is not an anomaly, but a rather common feature that the higher you go the abstraction layer the more complex in behaviour functions get. ‘open’ system call gives you a binary stream, C’s ‘fopen’ will handle line breaks for you transparently, Python’s ‘open’ will further decode binary stream into Unicode. This is not limited to system calls. In user space libraries more complex libraries are built on top of simpler ones to provide more features. That’s how software engineering works.

Kernel introduces another aspect. ‘mount’ system call does not detect file system because that can be done in user space. Generally anything that can be done in user space without big impact on performance should be as it makes the overall system more secure.

If you want something that works just like the mount command, and you don't care how long it takes, then just call the mount command.

system("mount foo /baz");

Originally Posted by smallpond If you want something that works just like the mount command, and you don't care how long it takes, then just call the mount command. system("mount foo /baz");

Poor to REALLY BAD security.

The problem is that it depends on three things... the environment PATH to find the mount command, the shell the system uses, and the mount command itself. Any of which can redirect to some unexpected program.

System (along with popen) are considered bad for these reasons.