ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
Quote:
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.
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:
Quote:
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()"?
Last edited by astrogeek; 08-17-2018 at 08:53 PM.
Reason: tpos, typs, typos, added thought...
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 ?
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.
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.
Code:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.