Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Ken Gosier writes: --- Scott Lanning <slanning at buphy.bu.edu> wrote: > Not Linux, but interesting to Linux users I think. > http://biz.yahoo.com/bw/000607/nj_bell_la.html Question: in the article, they list as being one of the radical ideas pioneered by Plan 9: "naming and accessing all system resources as if they were files" How is this different from what Unix does? Nobody elese seems to have commented on this ... Unix did have this design originally, of course, but there have been numerous failures to follow through. For example, the first Unix systems didn't have the /proc file system, and process's address spaces weren't available as files. This led to some rather clumsy code for interactive debuggers before people copied the (Bell Labs) /proc idea. The BSD networking code makes an interface a special sort of thing that isn't accessible as a file. This has been semi-fixed on a few kinds of unix systems, but it is still a problem on most. I worked on some Ultrix machines a few years ago that had a kind of interface that was also in /dev as a special file, which was really nice. A process could open the interface as a file, give it an IP address, and read and write raw packets. This made it possible to put other devices on the internet without needing access to the kernel. Another example is all the windows I see on my display. I did a project many years ago on Sun's early SunView window system, where each screen widget was in fact a file. When you created a window, you got back a file handle. If you added frames or menus or whatever to the window, each was an open file. This had one major problem: The kernel limited a process to 20 open files. This seriously limited the number of widgets you could have inside a window. They didn't seem to be able to see the obvious solution of upping the open-file limit to several K; they went to a totally new window system instead. The X window system is also outside the file system, for pretty much the same reason. You can't use a windowing system unless you can create at least hundreds of widgets in a window; if you want the code to be portable, you can't use files for the widgets. Some species of Unix now have memory-mapped files, which is really handy for some applications, but most Unices don't have this (yet). So while your memory may be organized as "objects" in some languages, these objects are usually not accessible through the file system. Acessing a database is never done through the file system, in my experience. You always go through a subroutine library that presents you with semantics that aren't at all file-like. Making any sort of object into a "file" is a useful design approach. It's too bad that the folks who have borught us Unix haven't seen fit to do it in general. It would simplify a lot of programming. Reports are that the Plan 9 people took the idea seriously and made pretty much everything into a file. It might be interesting to hear about the good and bad things that resulted, and how thorough a job they really did of it. - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |