/proc/mounts or /proc/mtab

/proc/mounts or /proc/mtab

Post by David W. Summe » Thu, 15 Feb 1996 04:00:00



I have included a patch to 1.3.63 to create a /proc/mtab or /proc/mounts
to display the file systems that are currently mounted in the same format as
/etc/mtab does.  My reasoning is thus:
   Why should mount have to write to a disk when the kernel has all that info
and it could be displayed with the /proc file?

What do people think of this?  Are there any good arguments for keeping
the /etc/mtab information on disk?  

During the transition to /proc/mtab (or /proc/mounts) we could symbolically
link /proc/mtab (or /proc/mounts) to /etc/mtab to keep from confusing
programs.

Please let me know what you think.

   - David Summers

--- linux/include/linux/proc_fs.h.orig  Sun Feb 11 17:26:56 1996

 #endif
        PROC_PROFILE, /* whether enabled or not */
        PROC_CMDLINE,
-       PROC_SYS
+       PROC_SYS,
+        PROC_MTAB
 };

 enum pid_directory_inos {
--- v1.3.52/linux/fs/proc/array.c       Fri Dec 29 07:35:28 1995

 #endif
 extern int get_device_list(char *);
 extern int get_filesystem_list(char *);
+extern int get_filesystem_info( char * );
 extern int get_irq_list(char *);
 extern int get_dma_list(char *);

 #endif
                case PROC_CMDLINE:
                        return get_cmdline(page);
+
+                case PROC_MTAB:
+                       return get_filesystem_info( page );
        }
        return -EBADF;
 }
--- v1.3.52/linux/fs/proc/root.c        1995/12/25 01:04:29     1.1

                PROC_CMDLINE, 7, "cmdline",
                S_IFREG | S_IRUGO, 1, 0, 0,
        });
+
+        proc_register( &proc_root, &(struct proc_dir_entry)
+           { PROC_MTAB, 6, "mounts", S_IFREG | S_IRUGO, 1, 0, 0, } );

        if (prof_shift) {
                proc_register(&proc_root, &(struct proc_dir_entry) {
--- v1.3.52/linux/fs/super.c    1995/12/25 00:50:22     1.1

        return retval;
 }

+int get_filesystem_info( char *buf )
+{
+struct vfsmount *tmp = vfsmntlist;
+int len = 0;
+
+while ( tmp && len < PAGE_SIZE - 80 )
+   {
+   len += sprintf( buf + len, "%s %s %s %s",
+      tmp->mnt_devname, tmp->mnt_dirname, tmp->mnt_sb->s_type->name,
+      tmp->mnt_flags & MS_RDONLY ? "ro" : "rw" );
+   len += sprintf( buf + len, " 0 0\n" );
+   tmp = tmp->mnt_next;
+   }
+
+return len;
+}
+
 int get_filesystem_list(char * buf)
 {
        int len = 0;

 
 
 

/proc/mounts or /proc/mtab

Post by Andries Brouw » Fri, 16 Feb 1996 04:00:00



: I have included a patch to 1.3.63 to create a /proc/mtab or /proc/mounts
: to display the file systems that are currently mounted in the same format as
: /etc/mtab does.  My reasoning is thus:
:    Why should mount have to write to a disk when the kernel has all that info
: and it could be displayed with the /proc file?

: What do people think of this?  Are there any good arguments for keeping
: the /etc/mtab information on disk?  

: During the transition to /proc/mtab (or /proc/mounts) we could symbolically
: link /proc/mtab (or /proc/mounts) to /etc/mtab to keep from confusing
: programs.

: Please let me know what you think.

Yes, this is a popular addition - several people have submitted
the same or very similar patches.
The disadvantage of this particular version is that it does not
give the mount options, or IP address for an NFS mount.
This means that it cannot at the moment replace /etc/mtab -
it gives strictly less information.

 
 
 

/proc/mounts or /proc/mtab

Post by Robert Bihlmey » Sat, 17 Feb 1996 04:00:00


Hi,

 David> I have included a patch to 1.3.63 to create a /proc/mtab or
 David> /proc/mounts to display the file systems that are currently
 David> mounted in the same format as /etc/mtab does.  My reasoning is
 David> thus: Why should mount have to write to a disk when the kernel
 David> has all that info and it could be displayed with the /proc
 David> file?

 David> What do people think of this?  Are there any good arguments
 David> for keeping the /etc/mtab information on disk?

This is a very nice feature and a way to get rid of the mtab-hack. I'm
running with /etc/mtab symlinked to /proc/mounts, right now. Now all
one has to do is to update (u)mount, make -n the default, let it use
/proc/mounts directly, and let go of /etc/mtab forever.

        Robbe

 
 
 

1. PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Just think about it for a minute.

There are three ways to address "/proc":
 - 100% binary interface
  * human interaction doesn't belong in the kernel - period.
 - optimally formated text
  * not designed for humans, but in human format ("text")
 - human readable
  * thus the entire OS is reduced to "cat" and "echo"

Providing more than one interface/format means code duplication.  It doesn't
matter how much is actually compiled.  Someone has to write it.  Others have
to maintain it.  Suddenly a change in one place becomes a change in dozens
of places.

Personally, I vote for a 100% binary interface. (no surprise there.)  It
makes things in kernel land so much cleaner, faster, and smaller.  Yes,
it increases the demands on userland to some degree.  However, printf/scanf
is one hell of a lot more wasteful than a simple mov.

For my worst case scenerio, answer this:
  How do you tell how many processors are in a Linux box?

The kernel already knows this, but it isn't exposed to userland.  So, one
must resort to ass-backward, stupid shit like counting entries in
/proc/cpuinfo.  And to make things even worse, the format is different for
every arch! (I've been bitching about this for four (4) years.)

And for those misguided people who think processing text is faster than
binary, you're idiots.  The values start out as binary, get converted to
text, copied to the user, and then converted back to binary.  How the hell
is that faster than copying the original binary value? (Answer: it isn't.)

And those who *will* complain that binary structures are hard to work with,
(you're idiots too :-)) a struct is far easier to deal with than text
processing, esp. for anyone who knows what they are doing.  Yes, changes
to the struct do tend to break applications, but the same thing happens
to text based inputs as well.  Perhaps some of you will remember the stink
that arose when the layout of /proc/meminfo changed (and broke, basically,
everything.)

--Ricky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Forwarding One RPC Service to Another?

3. PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

4. Xircom Cardbus etc

5. Problem with different /etc/mtab and /proc/mounts,cannot remount rw

6. how to implement

7. About /etc/mtab and /proc/mounts

8. kernel threads.

9. on /etc/mtab vs. /proc/mounts (Was RE: Linux should better cope w ith power failure)

10. Mounting proc fs to /mnt/root/proc ?

11. Solved: mount -t proc none /proc says "only root" // pivot_root

12. What happened to /proc/mtab?