u8acb@ohm.york.ac.uk (+Alex Barclay) (06/28/91)
I have just upgraded my ageing distribution of 1.2 minix to 1.3 and what do I find.... The _port_in and _port_out have been moved out of klib88.s and into libc.a. Why bother to have an operating system in the first place if you are going to allow users to access the hardware????? I always worked to a very simple rule when deciding if a routine belonged in the kernel or elsewhere. I ask myself "Does it access hardware?" If the answer is yes then it goes in the kernel... NO EXCEPTIONS. If the answer is no then it's a toss up as to wether it belongs in a user process (daemon) or in a system task. Like mm and fs in minix. What is going on here? Have I got hold of the wrong end of the stick here or is 1.3 the biggest mistake since VMS?? Surely you people out there in netland have some views about this. Lets hear them!!!! Alex. -- She stares at the screen, At the little words of green, Tries to remember what to do next. 225 - NMA acb5@vaxa.york.ac.uk (Main) or u8acb@ohm.york.ac.uk (Dept)
sfreed@ariel.unm.edu (Steven Freed CIRT) (06/29/91)
In article <1991Jun28.134614.11869@ohm.york.ac.uk>, u8acb@ohm.york.ac.uk (+Alex Barclay) writes: > into libc.a. Why bother to have an operating system in the first place if > you are going to allow users to access the hardware????? > I always worked to a very simple rule when deciding if a routine belonged > in the kernel or elsewhere. I ask myself "Does it access hardware?" If the > answer is yes then it goes in the kernel... NO EXCEPTIONS. If the answer is > no then it's a toss up as to wether it belongs in a user process (daemon) > or in a system task. Like mm and fs in minix. It's a good thing for you that Minix isn't based on the Mach philosopy. The Mach kerel is made to be as small and as fast as possible. One way this has been done is to take everything possible out of the kernel. This actually can be a very good thing. It allows the common user to write his own device drivers and even file systems. And it makes debugging such things much easier. You can make changes in the device drivers without having to recompile the kernel. In fact, it is then possible to load new device drivers without have to reboot the machine. As far as file systems go, most are written to be generic, to perform reasonably well in most circumstances. If you have direct access to the hardware, then a section of the disk can be set aside for you and you can then design your own filesystem that is tuned for your specific application. Since, among other things, Minix is a teaching tool, it would be neat if the users could have this level of control. Imagine the assignment: Go design and implement a file system for........ -- Steve. sfreed@ariel.unm.edu
wjb@cogsci.cog.jhu.edu (06/30/91)
>I have just upgraded my ageing distribution of 1.2 minix to 1.3 and what do >I find.... The _port_in and _port_out have been moved out of klib88.s and >into libc.a. Why bother to have an operating system in the first place if >you are going to allow users to access the hardware????? Since the 8088 doesn't have any mode where the INP or OUT instructions are disallowed it really doesn't matter whether they are in libc.a or not. Since you can always insert them directly into your binaries or write your own routines in assembler there wasn't any reduction in the security of the system. >I always worked to a very simple rule when deciding if a routine belonged >in the kernel or elsewhere. I ask myself "Does it access hardware?" If the >answer is yes then it goes in the kernel... NO EXCEPTIONS. If the answer is >no then it's a toss up as to wether it belongs in a user process (daemon) >or in a system task. Like mm and fs in minix. > >What is going on here? Have I got hold of the wrong end of the stick here >or is 1.3 the biggest mistake since VMS?? It isn't alway practical or reasonable to write new kernel code for every possible operation which you might want to do to hardware. A good example would be the code that reads the battery-backed clock on the PC. Is there any reason to have this code linked into the kernel and permanently resident in memory? It is likely to only get executed once at boot time from the the /etc/rc script. Actually, in 1.3, I believe that access was made via the /dev/port file and that can be protected to any level that you want. In the protected mode version for the 80286, the protection even means something. Do you also object to the /dev/mem or /dev/kmem files? Are IO port addresses all that different from arbitrary physical memory addresses? Just as dangereous and sometimes just as useful. One of the original strong points of Unix, was that it tried to provide a small general system. It does 90% of the job because that is in fact more then most people really need. Sometimes there just isn't any clean elegant way (or it isn't worth spending the time) to do something. Take a look at the "ps" command. Until fairly recently (3-4 years), on every Unix system it got its information from reading the symbol table of the kernel and groveling through /dev/kmem. It wasn't completely accurate all the time, but quite functional. Some newer systems now have system calls or libraries to provide such information, but they can provide just as inconsistent a view of the system. (Processes can be created and/or die during the system call.) Rules are a good thing, but sometimes you have to break them. The best systems are designed by people who come up with good rules and then aren't afraid to break them when it is appropriate to do so. Bill Bogstad