>
> Mark H. Wood writes:
>
> > Oh, no! Here it comes again. Perhaps much more important than
> > endianness or punctuation is once and for all settling the question
> > of whether /proc is for humans or for programs. Because these two
> > types of entities have different, often diametrically-opposed,
> > formatting requirements.
> >
> > (My take on this question is that programs should not be looking
> > in /proc at all; everything shown there should be available in
> > binary form via syscall,
>
> Oh yes! I really hate to parse /proc files. Parsing is not at all
> reliable, considering unexpected format changes and spelling fixes.
>
> It would be nice to cut down on the in-kernel data formatting too.
Damn, it's about the first time I agree with Albert. get_filesystem_info()
and getfilesystem_list() in fs/super.c are, erm, not fancy.
Related thing: we implement only subset of statfs() and it doesn't
include mountpoint. It's not that nice by itself, moreover, it doesn't
allow _very_ conveinent thing - getfsstat(). It's BSD syscall and it does
statfs() on all mounted filesystems, putting results into the buffer
passed by user. Return value - number of struct statfs actually written.
Since BSD struct statfs includes the mountpoint... Very convenient, since
it gives reliable way to (a) obtain the list of mounted filesystems and
(b) get stats on them. That's without procfs mounted and without fiddling
with /etc/mtab. Sigh...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/