Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why is procfs deprecated in favor of procstat?

11 views
Skip to first unread message

Kelly Dean

unread,
Feb 20, 2011, 4:25:29 AM2/20/11
to
http://ivoras.sharanet.org/freebsd/freebsd8.html says that procfs is deprecated in favor of procstat. But Plan 9 says that procfs is the right way to do things. I can't find any explanation why it's deprecated in FreeBSD.



_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-...@freebsd.org"

Oliver Fromme

unread,
Feb 21, 2011, 12:07:38 PM2/21/11
to
Kelly Dean <kelly...@yahoo.com> wrote:
> http://ivoras.sharanet.org/freebsd/freebsd8.html says that
> procfs is deprecated in favor of procstat. But Plan 9 says
> that procfs is the right way to do things.

Linux says the same. But it's irrelevant what they say.
FreeBSD is not Plan 9, and FreeBSD is not Linux.

Procfs has a long history of security vulnerabilities and
other problems. I do not mount procfs on most machines
I'm responsible for, especially not on machines that have
user accounts or services that are not restricted to jails.

I also think it is inefficient to let the kernel render
data to ASCII, and then have userland tools parse that
ASCII data again. That's ridiculous. There is no sane
reason for putting kernel data as ASCII text into a pseudo
file system.

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

"anyone new to programming should be kept as far from C++ as
possible; actually showing the stuff should be considered a
criminal offence" -- Jacek Generowicz

Jeremy Chadwick

unread,
Feb 21, 2011, 12:41:00 PM2/21/11
to
On Mon, Feb 21, 2011 at 06:07:38PM +0100, Oliver Fromme wrote:
> Kelly Dean <kelly...@yahoo.com> wrote:
> > http://ivoras.sharanet.org/freebsd/freebsd8.html says that
> > procfs is deprecated in favor of procstat. But Plan 9 says
> > that procfs is the right way to do things.
>
> Linux says the same. But it's irrelevant what they say.
> FreeBSD is not Plan 9, and FreeBSD is not Linux.
>
> Procfs has a long history of security vulnerabilities and
> other problems. I do not mount procfs on most machines
> I'm responsible for, especially not on machines that have
> user accounts or services that are not restricted to jails.
>
> I also think it is inefficient to let the kernel render
> data to ASCII, and then have userland tools parse that
> ASCII data again. That's ridiculous. There is no sane
> reason for putting kernel data as ASCII text into a pseudo
> file system.

I don't want to start a debate, but I disagree on the last point. If
anything, the filesystem concept for data acquisition (from the kernel)
most definitely falls under the "true UNIX way". I disagree with this
data being made available under /proc, but I do feel what's provided as
a simple file-based interface is the Right Thing(tm). Here's why:

Programmers are strictly limited to the sysctl(3) interface, or get to
do horrible things like fork()/exec() sysctl(8) repetitively for data.
How efficient! Aside from C, I'm not aware of any programming languages
that have native tie-ins to sysctl(3). I am explicitly excluding
third-party modules for perl and other whatnots; they're silly. With a
filesystem that provides sysctl data, you can literally use anything you
want to get information: /bin/sh, python, perl, PHP, Tcl/Tk, Ruby, Java,
or anything else.

As it stands today, the programming language is effectively made
retarded by repetitive calls to sysctl(8) to get data, check exit codes,
not to mention the repetitive fork()/exec() requirements.

For years now I have been considering a sysctl filesystem (e.g. mounted
as /sysctl) which would solve this dilemma. Read-only might be a wise
choice for this too. But this is beyond my skill set at this time, and
the existing documentation/examples for a pseudo filesystem are really
not that great.

By the way, did you know present-day FreeBSD "ps -e" doesn't work? Try
it and notice what the first line of output is. There are some other
base system utilities that behave the same way (thing-X doesn't work
without procps, and god forbid you use/mount it). I agree that procps
should be removed, but the way this came about was obviously done in
haste. Not cool.

--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |

Kelly Dean

unread,
Feb 22, 2011, 3:45:36 AM2/22/11
to
I see five different issues, so I need to clarify which one I was asking about.

1. How to request the data in question from the kernel: by reading a file, or by making a dedicated system call. Jeremy says read a file.

2. The format the kernel returns the data in. Oliver says the Plan 9 way of the kernel rendering text and then userland tools parsing text is silly. The kernel should return binary, which userland tools can then use directly, or render to text for a person to read.

3. Conflating /proc with Jeremy's /sysctl.

4. Whether /proc and/or /sysctl should be read-only.

5. Whether things in different security domains should see the same procfs.

The question I meant to ask was just the first one. What's wrong with requesting the data by reading a file instead of making a dedicated system call? What's the advantage of the system call?

But since the other issues came up: 2, I agree the kernel should return binary. 3, separate /proc and /sysctl. 4, no comment. 5, Oliver, didn't you answer your own objection? If things are supposed to be in the same security domain, then there can't be a vulnerability caused by them sharing a common procfs, and if they're supposed to be in different security domains, then put them in jails, where they don't share a common procfs.

Jeremy, when you said procfs should be removed, did you mean just for the same reasons Oliver said, or did you have other reasons?

Jeremy Chadwick

unread,
Feb 22, 2011, 4:52:11 AM2/22/11
to
On Tue, Feb 22, 2011 at 12:45:36AM -0800, Kelly Dean wrote:
> [ snipping stuff that I have no real response to :-) ]

>
> Jeremy, when you said procfs should be removed, did you mean just for
> the same reasons Oliver said, or did you have other reasons?

The security issues are long-standing and there have been many over the
years, but the real reason is something that's less evident (or at least
less directly apparent):

Simply put, procfs on FreeBSD has been neglected. There isn't a lot of
attention being given to it, and the only modifications in recent
months/years have been generally minor compared to the rest of the tree.
You can review some of the commits yourself:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/procfs/

Others like yourself have asked what the state of procfs is, going back
as far as 2005. Be sure to read the reply as well:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2005-05/2607.html

There was also a commit comment circa 2008 to the RELENG_7 branch that
indicates procfs is "now-deprecated":

http://freshbsd.org/2008/04/10/20/54/02

...yet there have been commits as recent as 2009 to fix important
utilities -- gcore(1) and gdb(1) -- to work without procps, which adds
further evidence that procfs may have been hastily forgotten/dropped
without a full review of what relied upon it:

http://freshbsd.org/2009/12/19/19/30/27

Alternate solutions or changes to procfs have been mentioned over the
years, such as in 2008 by a user on freebsd-arch, who received no reply:

http://lists.freebsd.org/pipermail/freebsd-arch/2008-March/007750.html

Finally, there is an official maintainer of procfs (see procfs.c at the
first link, then look for the Sep 23 2009 commit). You may want to
privately ask that individual what the current state of affairs is.

The /sysctl filesystem idea I've had I still feel is the best solution,
but *should not* be based on the procfs code (they're two different
beasts, despite having similar functionality). It should be written
from scratch.

I was quite serious when I said I wish I could write such a thing,
because the benefits of such are huge, especially when it comes to *any*
form of counter/statistic-gathering or monitoring capability on FreeBSD.
Honestly, it's a project that seems perfect for GSoC.

--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |

_______________________________________________

John Baldwin

unread,
Feb 22, 2011, 9:31:17 AM2/22/11
to
On Tuesday, February 22, 2011 4:52:11 am Jeremy Chadwick wrote:
> On Tue, Feb 22, 2011 at 12:45:36AM -0800, Kelly Dean wrote:
> > [ snipping stuff that I have no real response to :-) ]
> >
> > Jeremy, when you said procfs should be removed, did you mean just for
> > the same reasons Oliver said, or did you have other reasons?
>
> The security issues are long-standing and there have been many over the
> years, but the real reason is something that's less evident (or at least
> less directly apparent):

Actually, the replacement for procfs is not sysctl, but ptrace(2), and there
has been a long-running process in place to migrate tools such as truss, etc.
from using procfs to use ptrace(2) instead and to add new features to
ptrace(2) when there were things it did not support that procfs did. One
could argue that some of the more recent things like the sysctl's for procstat
-v or procstat -k should have been implemented as new ptrace OPs rather than
sysctls (and I'd probably agree with you).

--
John Baldwin

Bob Friesenhahn

unread,
Feb 22, 2011, 2:10:57 PM2/22/11
to
On Tue, 22 Feb 2011, John Baldwin wrote:
>
> Actually, the replacement for procfs is not sysctl, but ptrace(2), and there

I have been following this discussion with my jaw agape. It seems
that the many men standing around this elephant are all perceiving
completely different things based on their own interests and
experiences.

My own software is using procfs to efficiently determine the path to
the currently running executable. I am sure that other software does
the same since Linux procfs (and probably OS X) supports the same
mechanism. It is difficult to imagine how this would be done via
ptrace(2).

Bob
--
Bob Friesenhahn
bfri...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

Kostik Belousov

unread,
Feb 22, 2011, 4:14:44 PM2/22/11
to
On Tue, Feb 22, 2011 at 01:10:57PM -0600, Bob Friesenhahn wrote:
> On Tue, 22 Feb 2011, John Baldwin wrote:
> >
> >Actually, the replacement for procfs is not sysctl, but ptrace(2), and
> >there
>
> I have been following this discussion with my jaw agape. It seems
> that the many men standing around this elephant are all perceiving
> completely different things based on their own interests and
> experiences.
>
> My own software is using procfs to efficiently determine the path to
> the currently running executable. I am sure that other software does
> the same since Linux procfs (and probably OS X) supports the same
> mechanism. It is difficult to imagine how this would be done via
> ptrace(2).
Look at the PT_VM_TIMESTAMP + PT_VM_ENTRY. You would iterate over
the the mappings in the address space and look at the binaries at
pve_path, if any. The one that is elf object f the ET_EXEC type
is the binary. It is somewhat clumsy but the end result is the same
as if reading /proc/<pid>/file.

Or, you use sysctl kern.proc.vmmap and get essentially the same data.
PT_VM_ENTRY was added long after the sysctl, I did not objected exactly
because ptrace(2) looked more logical.

The advantage of using procfs or sysctl instead of ptrace(2) is that
you do not need to attach as debugger, causing the issues with signal
delivery for the debugee.

Pawel Jakub Dawidek

unread,
Feb 23, 2011, 3:57:56 AM2/23/11
to
On Mon, Feb 21, 2011 at 09:41:00AM -0800, Jeremy Chadwick wrote:
> For years now I have been considering a sysctl filesystem (e.g. mounted
> as /sysctl) which would solve this dilemma. Read-only might be a wise
> choice for this too. But this is beyond my skill set at this time, and
> the existing documentation/examples for a pseudo filesystem are really
> not that great.

http://www.mail-archive.com/freebsd...@freebsd.org/msg38829.html

:)

--
Pawel Jakub Dawidek http://www.wheelsystems.com
p...@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!

Damien Fleuriot

unread,
Feb 23, 2011, 4:31:41 AM2/23/11
to
On 2/23/11 9:57 AM, Pawel Jakub Dawidek wrote:
> On Mon, Feb 21, 2011 at 09:41:00AM -0800, Jeremy Chadwick wrote:
>> For years now I have been considering a sysctl filesystem (e.g. mounted
>> as /sysctl) which would solve this dilemma. Read-only might be a wise
>> choice for this too. But this is beyond my skill set at this time, and
>> the existing documentation/examples for a pseudo filesystem are really
>> not that great.
>
> http://www.mail-archive.com/freebsd...@freebsd.org/msg38829.html
>
> :)
>


Yummy :)


Find below the make output on 8.2-PRERELEASE 21/02/2011

I suppose a lot of stuff changed since 2002 and an update would be required.


--
mybsd root /tmp/sysctlfs/sysctlfs

# make
"/usr/share/mk/bsd.compat.mk", line 35: warning: NOMAN is deprecated in
favour of NO_MAN
Warning: Object directory not changed from original /tmp/sysctlfs/sysctlfs
@ -> /usr/src/sys
machine -> /usr/src/sys/amd64/include
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387
-mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -c sysctlfs_subr.c
In file included from sysctlfs_subr.c:16:
vnode.h:46:26: error: machine/lock.h: No such file or directory
In file included from sysctlfs_subr.c:16:
vnode.h:118: error: field 'v_interlock' has incomplete type
vnode.h:127: error: field 'vpi_lock' has incomplete type
vnode.h:128: error: field 'vpi_selinfo' has incomplete type
vnode.h:183: error: expected specifier-qualifier-list before 'udev_t'
In file included from vnode_if.h:10,
from vnode.h:532,
from sysctlfs_subr.c:16:
vnode_if_newproto.h:11: error: expected specifier-qualifier-list before
'vop_bypass_t'
cc1: warnings being treated as errors
In file included from vnode.h:532,
from sysctlfs_subr.c:16:
vnode_if.h: In function 'VOP_ISLOCKED':
vnode_if.h:28: warning: passing argument 1 of 'VOP_ISLOCKED_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_LOOKUP':
vnode_if.h:54: warning: passing argument 1 of 'VOP_LOOKUP_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_CACHEDLOOKUP':
vnode_if.h:80: warning: passing argument 1 of 'VOP_CACHEDLOOKUP_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_CREATE':
vnode_if.h:109: warning: passing argument 1 of 'VOP_CREATE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_WHITEOUT':
vnode_if.h:135: warning: passing argument 1 of 'VOP_WHITEOUT_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_MKNOD':
vnode_if.h:164: warning: passing argument 1 of 'VOP_MKNOD_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_OPEN':
vnode_if.h:196: warning: passing argument 1 of 'VOP_OPEN_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_CLOSE':
vnode_if.h:225: warning: passing argument 1 of 'VOP_CLOSE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ACCESS':
vnode_if.h:254: warning: passing argument 1 of 'VOP_ACCESS_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ACCESSX':
vnode_if.h:283: warning: passing argument 1 of 'VOP_ACCESSX_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_GETATTR':
vnode_if.h:309: warning: passing argument 1 of 'VOP_GETATTR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_SETATTR':
vnode_if.h:335: warning: passing argument 1 of 'VOP_SETATTR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_MARKATIME':
vnode_if.h:355: warning: passing argument 1 of 'VOP_MARKATIME_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_READ':
vnode_if.h:384: warning: passing argument 1 of 'VOP_READ_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_WRITE':
vnode_if.h:413: warning: passing argument 1 of 'VOP_WRITE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_IOCTL':
vnode_if.h:448: warning: passing argument 1 of 'VOP_IOCTL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_POLL':
vnode_if.h:477: warning: passing argument 1 of 'VOP_POLL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_KQFILTER':
vnode_if.h:500: warning: passing argument 1 of 'VOP_KQFILTER_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_REVOKE':
vnode_if.h:523: warning: passing argument 1 of 'VOP_REVOKE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_FSYNC':
vnode_if.h:549: warning: passing argument 1 of 'VOP_FSYNC_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_REMOVE':
vnode_if.h:575: warning: passing argument 1 of 'VOP_REMOVE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_LINK':
vnode_if.h:601: warning: passing argument 1 of 'VOP_LINK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_RENAME':
vnode_if.h:636: warning: passing argument 1 of 'VOP_RENAME_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_MKDIR':
vnode_if.h:665: warning: passing argument 1 of 'VOP_MKDIR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_RMDIR':
vnode_if.h:691: warning: passing argument 1 of 'VOP_RMDIR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_SYMLINK':
vnode_if.h:723: warning: passing argument 1 of 'VOP_SYMLINK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_READDIR':
vnode_if.h:758: warning: passing argument 1 of 'VOP_READDIR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_READLINK':
vnode_if.h:784: warning: passing argument 1 of 'VOP_READLINK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_INACTIVE':
vnode_if.h:807: warning: passing argument 1 of 'VOP_INACTIVE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_RECLAIM':
vnode_if.h:830: warning: passing argument 1 of 'VOP_RECLAIM_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_LOCK1':
vnode_if.h:859: warning: passing argument 1 of 'VOP_LOCK1_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_UNLOCK':
vnode_if.h:882: warning: passing argument 1 of 'VOP_UNLOCK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_BMAP':
vnode_if.h:917: warning: passing argument 1 of 'VOP_BMAP_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_STRATEGY':
vnode_if.h:940: warning: passing argument 1 of 'VOP_STRATEGY_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_GETWRITEMOUNT':
vnode_if.h:963: warning: passing argument 1 of 'VOP_GETWRITEMOUNT_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_PRINT':
vnode_if.h:983: warning: passing argument 1 of 'VOP_PRINT_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_PATHCONF':
vnode_if.h:1009: warning: passing argument 1 of 'VOP_PATHCONF_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ADVLOCK':
vnode_if.h:1041: warning: passing argument 1 of 'VOP_ADVLOCK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ADVLOCKASYNC':
vnode_if.h:1079: warning: passing argument 1 of 'VOP_ADVLOCKASYNC_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_REALLOCBLKS':
vnode_if.h:1102: warning: passing argument 1 of 'VOP_REALLOCBLKS_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_GETPAGES':
vnode_if.h:1134: warning: passing argument 1 of 'VOP_GETPAGES_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_PUTPAGES':
vnode_if.h:1169: warning: passing argument 1 of 'VOP_PUTPAGES_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_GETACL':
vnode_if.h:1201: warning: passing argument 1 of 'VOP_GETACL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_SETACL':
vnode_if.h:1233: warning: passing argument 1 of 'VOP_SETACL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ACLCHECK':
vnode_if.h:1265: warning: passing argument 1 of 'VOP_ACLCHECK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_CLOSEEXTATTR':
vnode_if.h:1294: warning: passing argument 1 of 'VOP_CLOSEEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_GETEXTATTR':
vnode_if.h:1332: warning: passing argument 1 of 'VOP_GETEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_LISTEXTATTR':
vnode_if.h:1367: warning: passing argument 1 of 'VOP_LISTEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_OPENEXTATTR':
vnode_if.h:1393: warning: passing argument 1 of 'VOP_OPENEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_DELETEEXTATTR':
vnode_if.h:1425: warning: passing argument 1 of 'VOP_DELETEEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_SETEXTATTR':
vnode_if.h:1460: warning: passing argument 1 of 'VOP_SETEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_SETLABEL':
vnode_if.h:1489: warning: passing argument 1 of 'VOP_SETLABEL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_VPTOFH':
vnode_if.h:1512: warning: passing argument 1 of 'VOP_VPTOFH_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_VPTOCNP':
vnode_if.h:1544: warning: passing argument 1 of 'VOP_VPTOCNP_APV' from
incompatible pointer type
In file included from sysctlfs_subr.c:16:
vnode.h: At top level:
vnode.h:551: warning: 'struct vop_lease_args' declared inside parameter list
vnode.h:551: warning: its scope is only this definition or declaration,
which is probably not what you want
vnode.h:554: error: expected declaration specifiers or '...' before 'udev_t'
vnode.h:568: warning: 'struct vop_lease_args' declared inside parameter list
vnode.h:619: warning: 'struct vop_lock_args' declared inside parameter list
vnode.h:622: warning: 'struct vop_lock_args' declared inside parameter list
vnode.h:628: warning: 'struct vop_lock_args' declared inside parameter list
vnode.h:636: warning: 'struct vop_createvobject_args' declared inside
parameter list
vnode.h:637: warning: 'struct vop_destroyvobject_args' declared inside
parameter list
vnode.h:638: warning: 'struct vop_getvobject_args' declared inside
parameter list
sysctlfs_subr.c: In function 'sysctlfs_allocvp':
sysctlfs_subr.c:152: error: 'securelevel' undeclared (first use in this
function)
sysctlfs_subr.c:152: error: (Each undeclared identifier is reported only
once
sysctlfs_subr.c:152: error: for each function it appears in.)
sysctlfs_subr.c:154: error: 'struct proc' has no member named 'p_prison'
sysctlfs_subr.c: In function 'sysctlfs_rw':
sysctlfs_subr.c:251: error: 'struct uio' has no member named 'uio_procp'
sysctlfs_subr.c: In function 'sysctlfs_sysctl':
sysctlfs_subr.c:353: error: 'struct sysctl_req' has no member named 'p'
sysctlfs_subr.c:376: error: 'securelevel' undeclared (first use in this
function)
sysctlfs_subr.c:382: error: 'struct sysctl_req' has no member named 'p'
sysctlfs_subr.c:383: warning: implicit declaration of function 'suser_xxx'
sysctlfs_subr.c:383: warning: nested extern declaration of 'suser_xxx'
sysctlfs_subr.c:383: error: 'struct sysctl_req' has no member named 'p'
sysctlfs_subr.c:384: error: 'PRISON_ROOT' undeclared (first use in this
function)
*** Error code 1

Stop in /tmp/sysctlfs/sysctlfs.
---

John Baldwin

unread,
Feb 23, 2011, 7:37:36 AM2/23/11
to
On Tuesday, February 22, 2011 2:10:57 pm Bob Friesenhahn wrote:
> On Tue, 22 Feb 2011, John Baldwin wrote:
> >
> > Actually, the replacement for procfs is not sysctl, but ptrace(2), and there
>
> I have been following this discussion with my jaw agape. It seems
> that the many men standing around this elephant are all perceiving
> completely different things based on their own interests and
> experiences.
>
> My own software is using procfs to efficiently determine the path to
> the currently running executable. I am sure that other software does
> the same since Linux procfs (and probably OS X) supports the same
> mechanism. It is difficult to imagine how this would be done via
> ptrace(2).

It would not be the first syscall to return a path to userland (see
__getcwd()). Presumably the reason a ptrace(2) OP has not been added
for that is that it is that nothing that was ported from procfs to
ptrace(2) has needed it.

--
John Baldwin

Martin Simmons

unread,
Feb 23, 2011, 10:13:24 AM2/23/11
to
>>>>> On Tue, 22 Feb 2011 23:14:44 +0200, Kostik Belousov said:

>
> On Tue, Feb 22, 2011 at 01:10:57PM -0600, Bob Friesenhahn wrote:
> > On Tue, 22 Feb 2011, John Baldwin wrote:
> > >
> > >Actually, the replacement for procfs is not sysctl, but ptrace(2), and
> > >there
> >
> > I have been following this discussion with my jaw agape. It seems
> > that the many men standing around this elephant are all perceiving
> > completely different things based on their own interests and
> > experiences.
> >
> > My own software is using procfs to efficiently determine the path to
> > the currently running executable. I am sure that other software does
> > the same since Linux procfs (and probably OS X) supports the same
> > mechanism. It is difficult to imagine how this would be done via
> > ptrace(2).
> Look at the PT_VM_TIMESTAMP + PT_VM_ENTRY. You would iterate over
> the the mappings in the address space and look at the binaries at
> pve_path, if any. The one that is elf object f the ET_EXEC type
> is the binary. It is somewhat clumsy but the end result is the same
> as if reading /proc/<pid>/file.
>
> Or, you use sysctl kern.proc.vmmap and get essentially the same data.
> PT_VM_ENTRY was added long after the sysctl, I did not objected exactly
> because ptrace(2) looked more logical.
>
> The advantage of using procfs or sysctl instead of ptrace(2) is that
> you do not need to attach as debugger, causing the issues with signal
> delivery for the debugee.

Another advantage I find of (linux) procfs is that you always get a textual
version of it, which can be useful in shell scripts and debugging situations.

/sbin/sysctl kern.proc.vmmap isn't usable because the command has no way to
specify the pid.

/usr/bin/procstat gives access to only part of the procfs and sysctl
namespace.

__Martin

Kostik Belousov

unread,
Feb 23, 2011, 10:34:19 AM2/23/11
to

Apparently, there is kern.proc.pathname sysctl and -b switch to procstat.
I never claimed that sysctls are useful from the command line, rather,
they form a binary interface for the programs.

Hugo Silva

unread,
Feb 23, 2011, 1:55:38 PM2/23/11
to
> For years now I have been considering a sysctl filesystem (e.g. mounted
> as /sysctl) which would solve this dilemma. Read-only might be a wise
> choice for this too. But this is beyond my skill set at this time, and
> the existing documentation/examples for a pseudo filesystem are really
> not that great.
>


http://netbsd.gw.com/cgi-bin/man-cgi?mount_sysctlfs++NetBSD-current

Julian Elischer

unread,
Feb 23, 2011, 9:35:02 PM2/23/11
to
On 2/21/11 9:07 AM, Oliver Fromme wrote:
> Kelly Dean<kelly...@yahoo.com> wrote:
> > http://ivoras.sharanet.org/freebsd/freebsd8.html says that
> > procfs is deprecated in favor of procstat. But Plan 9 says
> > that procfs is the right way to do things.
>
> Linux says the same. But it's irrelevant what they say.
> FreeBSD is not Plan 9, and FreeBSD is not Linux.
>
> Procfs has a long history of security vulnerabilities and
> other problems. I do not mount procfs on most machines
> I'm responsible for, especially not on machines that have
> user accounts or services that are not restricted to jails.
>
> I also think it is inefficient to let the kernel render
> data to ASCII, and then have userland tools parse that
> ASCII data again. That's ridiculous.
I disagree. It was ridiculous when pdp-11s had 500,000 instructions
per second
but there are many cases to day where it is not ridiculous.
I don't think that procfs is by definition bad, and I am no really
sure where this
"edict" has come from.

At fusion-io we have abstracted the control stuff
to export as sysctl when compiled in the freebsd driver and procfs in
the linux driver.
While sysctl is 'ok' I will admit that the procfs variant is a bit
more convenient to use.
simply because you can enumerate the damned tree without seeing all
the contents.

> There is no sane
> reason for putting kernel data as ASCII text into a pseudo
> file system.
>

> Best regards
> Oliver

Jeremy Chadwick

unread,
Feb 23, 2011, 10:50:05 PM2/23/11
to
On Wed, Feb 23, 2011 at 06:55:38PM +0000, Hugo Silva wrote:
> >For years now I have been considering a sysctl filesystem (e.g. mounted
> >as /sysctl) which would solve this dilemma. Read-only might be a wise
> >choice for this too. But this is beyond my skill set at this time, and
> >the existing documentation/examples for a pseudo filesystem are really
> >not that great.
> >
>
> http://netbsd.gw.com/cgi-bin/man-cgi?mount_sysctlfs++NetBSD-current

This is fantastic, except for the fact that it's abstracted by something
called puffs. I took a look at the NetBSD source code for this
(src/usr.sbin/puffs/mount_sysctlfs, tag netbsd-5) and puffs is
absolutely required for it to work.

http://netbsd.gw.com/cgi-bin/man-cgi?puffs+4+NetBSD-current
http://netbsd.gw.com/cgi-bin/man-cgi?puffs+3+NetBSD-current

Simply put, someone would have to port puffs for mount_sysctlfs to work
on FreeBSD. There is already efforts underway to do that, but I have
absolutely no idea what the status of it is:

http://wiki.freebsd.org/SOC2009TatsianaSeveryna

--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |

_______________________________________________

Martin Simmons

unread,
Feb 24, 2011, 5:55:21 AM2/24/11
to
>>>>> On Wed, 23 Feb 2011 18:35:02 -0800, Julian Elischer said:
>
> While sysctl is 'ok' I will admit that the procfs variant is a bit
> more convenient to use.
> simply because you can enumerate the damned tree without seeing all
> the contents.

If by contents you mean values then try the sysctl -N option (though that
still does a recursive enumeration).

__Martin

0 new messages