|
NetBSD General Other questions regarding NetBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|
|||
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) |
|
|||
"/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. |
|
||||
/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. |
|
|||
Hello,
Could you expand on this a little more?
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14) |
|
|||
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) |
|
||||
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
__________________
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. |
|
|||
Quote:
Code:
echo term > /proc/[pid]/ctl Of course the mount_procfs(8) man page has all the info you need to find out what each file does in /proc. |
|
|||
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) |
|
|||
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 |
|
|||
Quote:
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. |
|
||||
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:
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''. |
|
|||
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) |
|
|||
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) |
|
|||
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. |
|
||||
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''. |
|
|||
Quote:
Quote:
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. |
|
|||
Heat of the moment, of coarse... apologies.
|
|
|
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 |