powers@cimbad.dec.com (Bill Powers) (11/09/88)
I had sent this msg, last week, but I don't think it made it to the
outside world, If this is the second time you have seen this msg from me,
please ignore it.
I have been using/playing with Minix for the ST for a couple of weeks
now, I think that it beats gemdos by a mile, even though it, at this point,
does not support all of the st's hardware. I have a few questions I hope
some of you might be able to answer for me.
1) I have a 1040ST, with a hard disk, and would like to abolish the ram
disk. It seems the main purpose of the ram disk was to make it usable
for floppy based systems. I have set my system up for now such that
the root file system is on partition 3, and /usr is on partition 4
partition 3 is formatted at 1 meg, and partition 4 is 10 meg. How
easy would it be to remove the ramdisk, and what areas/routines would
need to be modified?
2) I guess this next question is more generic in nature towards UNIX
in general. Are there standard system calls in most unix systems
for doing graphics/windowing functions, which something like X-Windows
relies on using, or how is their functionality usually achieved?
3) If I spawn a couple of processes from a program, is their a mechanism
for one process to send stuff to another process, like mailboxes in
VMS.
4) In the atari implementation, are the processes protected from blasting
one another, or the kernel? I believe there are fence registers which
can be set in one of the atari custom chips, to generate a trap, if
you try to access outside your space. I believe this is how Atari
protects the first couple of K of ram where they store system vars
for gemdos. You can't blast the os, it's in rom, but thats ok, Atari
pre-blasted it for us, it's so full of bugs ;^)
5) Are there any particular reasons why the minix couldn't keep the
heep, and processes can take as much of it as is available, instead
of each process having a separate stack/heap area, which is I believe
how it works now.
Also, does anyone elses grep function generate a memory error when
it finds an occurance of the expression, in the file you are searching?
This is what happens on my st, and I haven't touched the code for
any of the commands yet.
Bill Powers
#include disclaimer.h
/*******************************************************************************
* If you had a VAXstation like me, you would be able to see the incredible 3d *
* graphics I've inserted at this point, but you don't, so you can't!!! *
*------------------------------------------------------------------------------*
* all flames to NL: not /dev/null since I use VMS on my VAXstation not U*IX *
*------------------------------------------------------------------------------*
* The opinions expressed herein are mine, and mine alone, but they can be made *
* yours if you send $19.95 plus $2.50 S&H to POWERS%DEVCIM.DEC@DECWRL.DEC.COM *
*******************************************************************************/henry@utzoo.uucp (Henry Spencer) (11/10/88)
In article <8811081753.AA18094@decwrl.dec.com> powers@cimbad.dec.com (Bill Powers) writes: > ... Are there standard system calls in most unix systems > for doing graphics/windowing functions, which something like X-Windows > relies on using, or how is their functionality usually achieved? Ha ha ha ho ho ho. There is nothing even remotely standard about the way graphics and windowing work under Unix; it's different every time. > 3) If I spawn a couple of processes from a program, is their a mechanism > for one process to send stuff to another process, like mailboxes in > VMS. Pipes. > 4) In the atari implementation, are the processes protected from blasting > one another, or the kernel? ... I'm not intimately familiar with ST Minix (yet), but the ST basically has essentially no protection hardware, so the answer is almost certainly "no". The ST has some sort of tweak for protecting low core, but that's *all* it can do. > 5) Are there any particular reasons why the minix couldn't keep the > heep, and processes can take as much of it as is available, instead > of each process having a separate stack/heap area, which is I believe > how it works now. The semantics of the sbrk() system call require a contiguous heap for each process. -- The Earth is our mother. | Henry Spencer at U of Toronto Zoology Our nine months are up. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
allbery@ncoast.UUCP (Brandon S. Allbery) (11/18/88)
As quoted from <1988Nov9.184419.3709@utzoo.uucp> by henry@utzoo.uucp (Henry Spencer): +--------------- | In article <8811081753.AA18094@decwrl.dec.com> powers@cimbad.dec.com (Bill Powers) writes: | > 3) If I spawn a couple of processes from a program, is their a mechanism | > for one process to send stuff to another process, like mailboxes in | > VMS. | | Pipes. +--------------- Try again. Minix is a message-passing OS; while I haven't tried it -- yet -- I haven't noticed anything that would prevent a process from doing sendmsg() to another non-kernel process. (Assuming the receiving process in question isn't already waiting on a message from the kernel, in which case things could get messy.) I daresay some form of message queueing to non-kernel processes should be implemented to make this work properly. Another -- tabled for the moment -- project of mine has what amounts to a "message server" which is capable of queueing messages. Perhaps such a beast should be implemented, similarly to INIT, and all messages be passed through it to other parts of the system. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
ncoverby@ndsuvax.UUCP (Glen Overby) (11/19/88)
In article <13142@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <1988Nov9.184419.3709@utzoo.uucp> by henry@utzoo.uucp (Henry Spencer): >| In article <8811081753.AA18094@decwrl.dec.com> powers@cimbad.dec.com (Bill Powers) writes: >| > 3) If I spawn a couple of processes from a program, is their a mechanism >| > for one process to send stuff to another process, like mailboxes in >| > VMS. >| >| Pipes. >Try again. Minix is a message-passing OS; while I haven't tried it -- yet >-- I haven't noticed anything that would prevent a process from doing >sendmsg() to another non-kernel process. Wrong. User processes can only do a SENDREC (send and receive) to/from FS and MM. For the evidence, look in src/kernel/proc.c: [ ... ] PUBLIC sys_call(function, caller, src_dest, m_ptr) [ ... ] /* Check for bad system call parameters. */ [ ... Line 106] if (function != BOTH && caller >= LOW_USER) { rp->p_reg[RET_REG] = E_NO_PERM; /* users only do BOTH */ return; } [ ... ] PUBLIC int mini_send(caller, dest, m_ptr) /* User processes are only allowed to send to FS and MM. Check for this. */ [ ... Line 143] if (caller >= LOW_USER && (dest != FS_PROC_NR && dest != MM_PROC_NR)) return(E_BAD_DEST); >Another -- tabled for the moment -- project of mine has what amounts to a >"message server" which is capable of queueing messages. Perhaps such a >beast should be implemented, similarly to INIT, and all messages be passed >through it to other parts of the system. Bing Bang implemented message queueing in his serial TTY driver for V1.2 I think implementing message queueing in a user process, while feasible, is the wrong way to go. It is best implemented in the kernel's own send and receive functions. Get Bing's serial driver stuff and look it over; he changed all the drivers and servers so that they were non-blocking. I understand that it actually gave decent multi-processing response time. A project I've been working on intermittently for about a year now is revamping the bootstrapper to read Minix from files, and a re-organization of the priority scheme; I'm switching to privilege bits for processing priority (device, server, user) and for message sending (open for receive, privileged for send). This would allow making certain processes privileged to send messages to any other process, a potential security breach because they could then send messages to any device task. Glen Overby uunet!ndsuvax!ncoverby ncoverby@ndsuvax (Bitnet) ncoverby@plains.nodak.edu