DaemonForums  

Go Back   DaemonForums > NetBSD > NetBSD General

NetBSD General Other questions regarding NetBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 8th July 2008
JMJ_coder JMJ_coder is offline
VPN Cryptographer
 
Join Date: May 2008
Posts: 464
Thanked 8 Times in 8 Posts
Default What's the deal with /proc?

Hello,

NetBSD has /proc in its file hierarchy, but it is empty. Do you have to do something to enable it, or is it just taking up listing space? It seems that it should be able to do something, especially since some programs in pkgsrc require it (i.e., htop).
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14)
Reply With Quote
  #2   (View Single Post)  
Old 8th July 2008
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

"/proc" is a System V thing, not really all that popular in the BSD world..

Still, What you're seeking is mount_procfs(8).

Last edited by BSDfan666; 8th July 2008 at 01:46 AM.
Reply With Quote
  #3   (View Single Post)  
Old 8th July 2008
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 563
Thanked 14 Times in 13 Posts
Default

/proc can also be mounted automatically with an /etc/fstab entry. Initially I had some trouble getting the right syntax via reading the man pages, but eventually found the following fstab entry did the trick in NetBSD 4.0:

Code:
procfs          /proc   procfs  rw,linux
The ",linux" bit is optional.
Reply With Quote
  #4   (View Single Post)  
Old 8th July 2008
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Thanked 112 Times in 104 Posts
Default

/proc is an 8th edition UNIX thing, SVR4 just made it famous.


Whether one wants to use such an interface or not is more of a taste issue imho.


binary or flat files in /proc or sysctl's, I like the file idea personally but don't really give a darn as long as the system provides documentation on what style interface to use.
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.

Last edited by TerryP; 8th July 2008 at 03:42 AM.
Reply With Quote
  #5   (View Single Post)  
Old 9th July 2008
JMJ_coder JMJ_coder is offline
VPN Cryptographer
 
Join Date: May 2008
Posts: 464
Thanked 8 Times in 8 Posts
Default

Hello,

Thanks. I don't use the /proc system all that much - but it was brought to my attention because I wanted to try htop and it required an active /proc.
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14)
Reply With Quote
  #6   (View Single Post)  
Old 9th July 2008
JMJ_coder JMJ_coder is offline
VPN Cryptographer
 
Join Date: May 2008
Posts: 464
Thanked 8 Times in 8 Posts
Default

Hello,

Quote:
Originally Posted by TerryP View Post
binary or flat files in /proc or sysctl's, I like the file idea personally but don't really give a darn as long as the system provides documentation on what style interface to use.
Could you expand on this a little more?
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14)
Reply With Quote
  #7   (View Single Post)  
Old 9th July 2008
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Thanked 112 Times in 104 Posts
Default

Unix generally provides an "every thing is a file" style of doing things.


You can read from files, you can write to files, you can ask files about themselves.


The command shell generally gives a file like interface for handling character based data streams as if they were files,

Code:
cat foo.ps | ps2ascii | sort
pkg_info > pkg_info.pre_foo_pkg

It works mostly the same way as that in the code, it really is that simple at heart.

Handing multiple processes via pipes like the shell uses are also similar in code. For example we can read from and write to a pipe (when set accordingly), just like if we ran the commands in the shell, only the user didn't have to use our program in a pipe line.


Sockets programming is really a lot like basic file input/output and related operations IMHO, just with "extra overhead" involved for the differences that connections, ports, and byte orders create, blah blah over the usual file system options.


Devices are generally implemented as block or character special files that represent an interface to the device.


If you want to print a file and redirect it's content to the printer device, say like

Code:
lptest > /dev/lpt0

Wouldn't it make sense for the lpt driver to accept writing data to it as instructions to send that data stream to the device connected ?

In essence making printing as conceptually simple as creating a stream of data the printer can understand from an input stream, then writing it out to the device. <-- don't you just love unix printing concepts?


[note: most of this is theory, I'm not familiar with the details of any current procfs implementations, nore do I wish to be since it's not common on my target systems]


So if we represent devices as files, why the hell not represent running processes as files?


That's basically what the "Process File System" or procfs is for.


Wouldn't it be cool if you wanted to kill a process by PID, and could just rm -rf /proc/PID ? Or what if you wanted to find out it's name and arguments, how about cat /proc/cmdline.



It's a simple interface to doing operating specific things. Everything is a file, so writing programs like ps, kill, and nice are just simple file I/O based on a defined file system hierarchy managed by the kernel.



I've never really used /proc because I've never used systems that required it for much but that is the value I see in it. Yes you could say I like /proc even through I hate stuff that *assumes* it is there and doesn't tell you.



Since the kernel and init are essentially processes 0 and 1 respectively if memory serves. It would make sense to have /proc/0 with files representing stuff specific to the given process, such as the kernel.

Why not use it?


Another form of interface to all that is via sysctl variables and what ever system calls are needed or desired to allow doing it from C programs.


It's just a different way of doing it.


Who cares if it is

Code:
# sysctl kern.maxproc=42

or

Code:
#echo 42 > /proc/0/maxproc

it all does the same thing, just a question of taste.


I personally feel that the second method is more "natural" and less "oh, what dang system call do I need" feeling at times. Especially on an operating system that is supposed to believe that "everything is a file".



Dang it, wouldn't it be really cool if you could do something like

Code:
# rm -f /users/luser.ptty0
and "terminate" an annoying users session on 'ptty0' >_>
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.

Last edited by TerryP; 10th July 2008 at 12:06 AM.
Reply With Quote
  #8   (View Single Post)  
Old 10th July 2008
Meta_Ridley Meta_Ridley is offline
OFM Addict
 
Join Date: May 2008
Posts: 21
Thanked 3 Times in 3 Posts
Default

Quote:
Originally Posted by TerryP View Post
Wouldn't it be cool if you wanted to kill a process by PID, and could just rm -rf /proc/PID ? Or what if you wanted to find out it's name and arguments, how about cat /proc/cmdline.
I know this is getting into implementation and practice, but I thought this would be helpful: that command doesn't work on NetBSD's proc filesystem. Instead you can send a signal to /proc/[pid]/ctl like this:
Code:
echo term > /proc/[pid]/ctl
You can also send "attach," "detach," "run," "step," and "wait" to it, in addition to the usual process signals, and it will do all of those things.

Of course the mount_procfs(8) man page has all the info you need to find out what each file does in /proc.
Reply With Quote
  #9   (View Single Post)  
Old 10th July 2008
JMJ_coder JMJ_coder is offline
VPN Cryptographer
 
Join Date: May 2008
Posts: 464
Thanked 8 Times in 8 Posts
Default

Hello,

So the sysctl is the binary way and proc is the file way? And sysctl is a binary file - not a plain text file? And sysctl is the default way for NetBSD? Why would NetBSD (or any *BSD, if proc is a SVR5 thing and sysctl is a *BSD thing) do something against one of the UNIX tenets - everything is a file?
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14)
Reply With Quote
Old 10th July 2008
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

The "ctl" utilities are a key part of BSD, they don't "ignore" the everything is a file concept.. but they also don't overuse it like Plan 9/Linux did/do.

Code:
bioctl     iopctl     pfctl      relayctl   sysctl     
atactl     dvmrpctl   ipsecctl   pppctl     ripctl
audioctl   mixerctl   radioctl   snmpctl    wsconsctl  
bgpctl     gpioctl    ospfctl    raidctl    swapctl     usbhidctl
Reply With Quote
Old 11th July 2008
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Thanked 112 Times in 104 Posts
Default

Well, I personally doubt that the functioning of /proc on any common systems would live up to my opinions of what it should be but that's just a fact of life.

Quote:
Originally Posted by myself
binary or flat files in /proc or sysctl's
What I meant by 'binary' was binary data stored in /proc/files rather then plain text.


sysctl is just a program used to get/set kernel state.


/sbin/sysctl, /proc/0/, /sysfs/, as long as it W_O_R_K_S ;-)
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
Reply With Quote
Old 11th July 2008
JMJ_coder JMJ_coder is offline
VPN Cryptographer
 
Join Date: May 2008
Posts: 464
Thanked 8 Times in 8 Posts
Default

Hello,

I guess I am having a difficult time at the moment understanding the workings of the "ctl" utilities and proc - and their similarities and differences - and how they fit in the *BSD and SVR5 and Linux way of doing things. I'm going to try to google around to try and find more information.
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14)
Reply With Quote
Old 11th July 2008
JMJ_coder JMJ_coder is offline
VPN Cryptographer
 
Join Date: May 2008
Posts: 464
Thanked 8 Times in 8 Posts
Default

Hello,

Also, where can I find all the options for the 'ctl' utilities and what they do? For instance, wsconsctl(8) doesn't tell hardly any of the options (only a couple examples - which is a good start) and none of what any do - i.e., it doesn't tell you that msg.default.fg changes the text console text color.
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14)
Reply With Quote
Old 11th July 2008
Meta_Ridley Meta_Ridley is offline
OFM Addict
 
Join Date: May 2008
Posts: 21
Thanked 3 Times in 3 Posts
Default

Quote:
Originally Posted by BSDfan666 View Post
The "ctl" utilities are a key part of BSD, they don't "ignore" the everything is a file concept.. but they also don't overuse it like Plan 9/Linux did/do.
I have to disagree with the "overuse" comment. Unix was originally designed to have everything accessible through the filesystem. Ironically it was the way the original BSD handled network devices that led future Unix and Unix-like OSs away from this idea. Plan 9 was/is (it's not dead; in fact it's still being actively developed, and under an open source license) a return to and an expansion on the idea, and the FUSE project is doing the same for Unix and Unix-like OSs, including NetBSD.

The idea behind using the filesystem is to give a consistent way to interact with the system, facilitating another tenet of Unix philosophy: "Do one thing and do it well." Of course many systems, for better or for worse, have gone away from that, but in general I think both using the filesystem to access everything and using small tools and putting them together instead of huge kitchen sink programs is the way I want to do things. It keeps things simple.

Last edited by Meta_Ridley; 11th July 2008 at 06:38 AM.
Reply With Quote
Old 11th July 2008
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

Well, clearly it's a mater of preference then... for example, I don't like FUSE or /proc.

And you're wrong, UNIX has always had "devices" to be represented as files.. process information should be obtained via a system call.
Reply With Quote
Old 11th July 2008
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Thanked 112 Times in 104 Posts
Default

Quote:
Originally Posted by BSDfan666 View Post
process information should be obtained via a system call.
Why ?


I know that File I/O like a lot of neat operations usually involves a fair bit of system calls but I assume you mean ones specific to process information ;-)



But imho, saying process information should be obtained via a system call, in the sense of a system call or system calls specifically designed just for the express purpose of pumping out that information. Is like saying bytes must be 8-bits long on every machine ever made.


It probably should be that way but people should also be free to try new and different things.
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
Reply With Quote
Old 11th July 2008
Meta_Ridley Meta_Ridley is offline
OFM Addict
 
Join Date: May 2008
Posts: 21
Thanked 3 Times in 3 Posts
Default

Quote:
Originally Posted by BSDfan666 View Post
Well, clearly it's a mater of preference then... for example, I don't like FUSE or /proc.
I'm glad we agree on something.

Quote:
Originally Posted by BSDfan666 View Post
And you're wrong, UNIX has always had "devices" to be represented as files.. process information should be obtained via a system call.
I'm guessing what you meant to say was that process information has been traditionally obtained via a system call. Is that correct? In any case, saying something is the way it is and saying what something should be are two different things. In essence by saying this you've contradicted your above statement, since by saying process info should be obtained via a system call you're leaving no room for others' preferences. What if someone created a Unix fork that had only the /proc filesystem and no system calls to get process information and prefers it be that way? Would you leave them alone, saying it's their preference and the preference of its users, or would you chastise them because they're not doing what you think they should do?

And yes, I made a mistake in saying that all information on the system was represented as files. That's true of devices, but not of processes until /proc came along.
Reply With Quote
Old 11th July 2008
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

Heat of the moment, of coarse... apologies.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
cant see screensaver or proceses in proc manager whispersGhost FreeBSD Installation and Upgrading 2 22nd January 2009 08:30 PM


All times are GMT. The time now is 02:25 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick