View Single Post
  #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
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