LISTSERV%DEARN.BITNET@wiscvm.wisc.edu (1.5j) (07/14/87)
Received: by DDAESA10 (Mailer X1.24) id 2839; Mon, 06 Jul 87 08:55:28 SET Date: Mon, 06 Jul 87 08:49:30 SET From: "N.Head" <ESC1111@DDAESA10> Subject: Archives ... To: MINIX-L@DEARN As a newcomer to this list (and as a new user of MINIX 1.1) I thought I would enquire whether archives of previous traffic are available s'where where a bitnetter can get to them. I notice that there appear to have been a lot of bug reports and fixes and would like to bring my copy up to date. Specific problems of the moment appear to be the printer driver (despite applying the LOW_FOUR fix I still get 'Printer error' [from lpr not the driver]) and the keyboard (an PREH Commander AT model where the numlock status doesn't seem to work right, particularly in mined with the cursor keys). I also heard that there are a number of shell bugs (but not further ....) so any help and enlightenment would be welcome. Nigel :-> (I LIKE it though) My system ? - AT klone, 8 Mhz, 2*20Meg Win, 1Mb, hercules graphics.
NU021172%NDSUVM1.BITNET@wiscvm.wisc.edu (Marty Hoag) (07/14/87)
The BITNET/EARN/Netnorth community can retrieve archives from LISTSERV machines at FINHUTC (separate entries) and NDSUVM1 (monthly notebooks). For more information send the command "INDEX MINIX-L" to either of these (eg. TELL LISTSERV AT NDSUVM1 INDEX MINIX-L or include the INDEX MINIX-L as the first ltext ine of a mail file. Some warnings: the NDSUVM1 logs are new and will be missing many historical entries. Also, the older entries might have to be purged to make way for new ones.
LISTSERV%IRISHVM.BITNET@wiscvm.wisc.edu (1.5i) (08/10/87)
Received: from UIUCVMD(MAILER) by IRISHVM (Mailer X1.23b) id 8466;
Mon, 10 Aug 87 15:05:22 EST
Received: by UIUCVMD (Mailer X1.24) id 7713; Mon, 10 Aug 87 15:05:56 CDT
Date: 10 August 1987 15:03:46 CDT
From: Bill Rogers <ROGERS@UIUCVMD>
To: <minix-l@irishvm>
Subject: 1.2 diff?
The 1.2 diffs didn't ever seem to come through this LISTSERVer
Will they, Could they, Will you?
Billmmdf@udel.UUCP (09/07/87)
UNSUBSCRIBE
LISTSERV%FINHUTC.BITNET@wiscvm.wisc.edu (1.5l) (10/01/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 0054;
Thu, 01 Oct 87 18:27:28 FIN
Received: by NDSUVM1 (Mailer X1.24) id 4856; Thu, 01 Oct 87 05:21:16 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 05:20:25 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa15352; 1 Oct 87 5:50 EDT
Received: from USENET by Louie.UDEL.EDU id aa15270; 1 Oct 87 5:44 EDT
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <6@unh.UUCP>
Newsgroups: comp.os.minix
Date: 30 Sep 87 15:27:32 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: "Kevin W. Gale" <kwg@unh.uucp>
Subject: Re: Turbo C & Minix v1.2; distribution via mail only
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
In article <777@cup.portal.com>, Gary_David_Archer@cup.portal.com writes:
> I'd also like them? Can you pass them on?
Me Too Please!LISTSERV%FINHUTC.BITNET@wiscvm.wisc.edu (1.5l) (10/01/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 0091;
Thu, 01 Oct 87 18:30:20 FIN
Received: by NDSUVM1 (Mailer X1.24) id 4703; Thu, 01 Oct 87 05:11:01 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 05:07:59 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa15177; 1 Oct 87 5:40 EDT
Received: from USENET by Louie.UDEL.EDU id aa15117; 1 Oct 87 5:35 EDT
Keywords: minix
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <1680@killer.UUCP>
Newsgroups: comp.os.minix,comp.arch,comp.unix.wizards
Date: 30 Sep 87 06:29:40 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: Jim Thrasher <termin@killer.uucp>
Subject: minix
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
This discussion that is spilling over from comp.arch and comp.unix.wizards
into the newgroup minix is getting to be a duplicity of effort. I do read the
discussion but I am reading it in 3 newsgroups now . IT DOES NOT NEED TO
BE PUT IN THE COMP.OS.MINIX NEWSGROUP. IF YOU CAN FIND SOMEONE TO HELP YOU
FIGURE OUT HOW TO PUT IT IN THE APPROPIATE NEWSGROUP IT WOULD BE APPRECIATED.
Thanks JimLISTSERV%FINHUTC.BITNET@wiscvm.wisc.edu (1.5l) (10/01/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 0242;
Thu, 01 Oct 87 18:34:22 FIN
Received: by NDSUVM1 (Mailer X1.24) id 5033; Thu, 01 Oct 87 05:33:34 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 05:31:24 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ab15352; 1 Oct 87 5:51 EDT
Received: from USENET by Louie.UDEL.EDU id aa15281; 1 Oct 87 5:44 EDT
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <8@unh.UUCP>
Newsgroups: comp.os.minix
Date: 30 Sep 87 15:42:44 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: "Kevin W. Gale" <kwg@unh.uucp>
Subject: Re: Turbo C & Minix v1.2; distribution via mail only
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
In article <777@cup.portal.com>, Gary_David_Archer@cup.portal.com writes:
> I'd also like them? Can you pass them on?
Sorry to post this again but my .sig didn't work the first time.
Anyway could someone e-mail me the 1.2 diffs if they exist.
--
God is omnipotent, omniscient, and omnibenevolent - it says so right here on th
e
label. If you have a mind capable of believing this I have a wonderful deal for
you. No checks please, Cash in small bills.
Kevin W. Gale seismo!uunet!unh!kwgLISTSERV%FINHUTC.BITNET@wiscvm.wisc.edu (1.5l) (10/01/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 0501;
Thu, 01 Oct 87 18:41:02 FIN
Received: by NDSUVM1 (Mailer X1.24) id 3713; Wed, 30 Sep 87 22:10:34 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Wed, 30 Sep 87 22:08:04 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa09888; 30 Sep 87 22:46 EDT
Received: from USENET by Louie.UDEL.EDU id aa09576; 30 Sep 87 22:42 EDT
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <543@bal.cs.vu.nl>
Newsgroups: comp.os.minix
Date: 30 Sep 87 13:16:55 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: Henri Bal <bal@cs.vu.nl>
Subject: bug in check_sig
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
The procedure check_sig in the file mm/signal.c contains the following bug.
If the signal to be checked is a SIGALRM, the statement on line 6617 (of the
original Minix Source Code contained in the book) causes the ALARM_ON bit
of every single process to be cleared. So, if an alarm goes off in one process,
all other processes that are sleeping will hang forever, because of the test
on line 6616. As an example, if you give the commands:
(sleep 20; echo A) &
(sleep 4; echo B) &
only a ``B'' will be printed. The ``sleep 20'' will never terminate.
To fix the problem, line 6617 should only clear the ALARM_ON bit if
send_sig is TRUE, so it should be changed into:
if (send_sig) rmp->mp_flags &= ~ALARM_ON;
Also note that the semantics of the alarm signal are subtly different from
the Unix semantics. In Unix, if you explicitly send an alarm signal
(e.g., by ``kill -14 pid'') to a process that is not sleeping, the process
will be killed. In Minix, the signal will be ignored (because of line 6616).LISTSERV%FINHUTC.BITNET@wiscvm.wisc.edu (1.5l) (10/01/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 1612;
Thu, 01 Oct 87 20:01:44 FIN
Received: by NDSUVM1 (Mailer X1.24) id 0647; Thu, 01 Oct 87 12:41:43 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 12:40:01 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa21795; 1 Oct 87 12:58 EDT
Received: from USENET by Louie.UDEL.EDU id aa21790; 1 Oct 87 12:57 EDT
Followup-To: comp.arch
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <4780@ncoast.UUCP>
Newsgroups: comp.unix.wizards,comp.os.minix
Date: 1 Oct 87 00:29:49 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: Brandon Allbery <allbery@ncoast.uucp>
Subject: Re: VM, Paging, Demand Paging
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
As quoted from <1755@ncr-sd.SanDiego.NCR.COM> by greg@ncr-sd.SanDiego.NCR.COM
(Greg Noel):
+---------------
| >In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes:
| >> ... the PDP-11 \does/ have virtual memory.
|
| In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
| >probably because it didn't in fact have the capability of supporting VM.
+---------------
Et cetera.
Definitions for the buzzwords people are bandying about with such abandon:
Virtual Memory: Any address scheme which allows the apparent memory space
visible to a process to be associated with the physical memory of a computer
by some mapping other than the identity transformation. To put that simply:
virtual memory is any system which allows address <x> within a process's
address space to be some value other than address <x> within the physical
address space of the computer.
Register-relative addressing is virtual memory by this definition, since
the register can contain any legal address without affecting the program.
Note than Intel segment registers are just a refinement of sorts on the
register-relative addressing scheme. This was also raised to a fine art
by IBM in its 360/370/43xx processor line.
===============
Paging: A virtual memory scheme which involves the division of physical
memory into "pages"; virtual memory spaces are similarly divided. The
mapping between virtual and physical addresses is such that consecutive
virtual segments need not be consecutive in physical memory. The majority
of MMU's (memory management units) operate in this way.
Note that, while most MMU's support paging, many operating systems do not
use it because it requires more work on their part to keep track of the
mapping between virtual and physical addresses for a process. The major
difference between System VR2 and System VR2.2 was that the latter had
support for paging; a process's address space was stored as a map of physical
segment addresses rather than a simple physical start address. (Operating
systems that do not use paging simply define all physical memory segments
as consecutive if the virtual segments they represent are consecutive. This
means less work for the operating system.)
===============
Demand Paging: This is a virtual memory scheme which allows a given "page"
of virtual memory to reside in secondary storage if it is not being accessed.
Note that "swapping" is "demand paging" where the "page" is the size of the
process's entire virtual address space. The benefit of demand paging is that
a part of a process's address space which is never accessed need never be
brought into memory at all, thus making more memory available to other
processes; and a part of a process's address space which is used only in-
frequently need only be loaded in main memory when it is actually being
used. Also, whereas a "swapping" system usually leaves a copy of the read-only
portion of a process in the swap area (thus taking up extra space on disk),
demand paging systems usually optimize this by realizing that the original
load file contains the read-only data space, so read-only address spaces are
never physically paged out and are always paged in from the executable load
file. On systems which support "copy on write" demand paging, portions of
the read-write space which are not altered by the process may also be paged
as if they were read-only; if they are altered, they will then be paged as
normal read-write address spaces. (This can produce a noticeable improvement
in system performance when a program has a large data structure allocated
in a read-write address space, large contiguous portions of which are not
used by a particular process. Statistical programs and fast-fourier
transforms come to mind.)
===============
So, with the definitions cleared up, we can clear up other questions:
(1) Yes, I was guilty of using the wrong terms when I lamented the lack of
"VM" on IBM PCs and clones thereof.
(2) Yes, the PDP-11 has virtual memory. It does not support paging or
demand paging, however. (I may be wrong about paging, I'm not a PDP-11
guru. But if it had VM, the VAX would never have been developed by DEC.)
--
Brandon S. Allbery, moderator of comp.sources.misc
{{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery
ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY
<<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>
"`You left off the thunderclap and the lightning flash.', I told him.
`Should I try again?' `Never mind.'" --Steven Brust, JHEREGLISTSERV%FINHUTC.BITNET@wiscvm.wisc.edu (1.5l) (10/02/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 2676;
Thu, 01 Oct 87 23:44:31 FIN
Received: by NDSUVM1 (Mailer X1.24) id 4728; Thu, 01 Oct 87 16:39:21 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 16:37:09 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa26298; 1 Oct 87 16:20 EDT
Received: from USENET by Louie.UDEL.EDU id aa26097; 1 Oct 87 16:09 EDT
Keywords: irrelevance, wasted bandwidth
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <1436@ogcvax.UUCP>
Newsgroups: comp.os.minix
Date: 29 Sep 87 19:35:00 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: Phil Miller <pcm@ogcvax.uucp>
Subject: Re: VM on PDP-11
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
When I went to read my comp.os.minix articles today, 4 of the 7 articles
were about virtual memory on the PDP-11. MUST this vacuous debate continue
within comp.os.minix? Flames to me directly, please -- enough comp.os.minix
space has already been wasted on this topic.mmdf@udel.UUCP (10/02/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 2738;
Fri, 02 Oct 87 00:21:14 FIN
Received: by NDSUVM1 (Mailer X1.24) id 5066; Thu, 01 Oct 87 17:07:32 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 17:05:22 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa27311; 1 Oct 87 17:32 EDT
Received: from USENET by Louie.UDEL.EDU id aa27198; 1 Oct 87 17:22 EDT
Keywords: what computer should I buy?
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <10774@beta.UUCP>
Newsgroups: comp.os.minix
Date: 1 Oct 87 19:45:38 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: Akkana <hp@beta.uucp>
Subject: What's the status of Minix?
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
This is probably something which comes up pretty often, but I've
scanned the comp.os.minix messages currently on this system and haven't
found any answers, so here goes:
What's the current status of Minix? What machines will run it? I
gather the Atari ST port has already been done (is that true?) -- how
about the Amiga port? Is there a serial driver yet, or uucp? Are
people generally happy with Minix?
I thought Minix was a great idea when it first came out, but since I
didn't have access to a PC I didn't buy it and stopped reading this
group. Now I find myself in a position where I'm thinking about
buying some sort of PC, and I'd like to try Minix, both because it
sounds like a good environment and because I'd like to support it.
I'd rather buy an Amiga than an ST (because the native OS looks better
and there's a lot more net support), but if Minix runs better on PC's
than on the 68000 machines I might buy a PC instead. The ability to
run a terminal emulator, uucp and/or Usenet on the machine would be a
big plus. (Ethernet support would be great, but I don't expect it yet.)
So, any suggestions? What's a good Minix machine? How are the various
ports going? Any advice to a potential new Minix user?
..
...Akkana Center for Nonlinear Studies, LANL
akkana%infidel@lanl.gov hp@lanl.gov ihnp4!lanl!hp
"I think I'll take a walk. Hmm, wonder where this wire goes?"
-- Max Headroommmdf@udel.UUCP (10/02/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 4157;
Fri, 02 Oct 87 04:36:54 FIN
Received: by NDSUVM1 (Mailer X1.24) id 9223; Thu, 01 Oct 87 21:29:31 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 21:25:23 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa00543; 1 Oct 87 21:58 EDT
Received: from USENET by Louie.UDEL.EDU id aa00423; 1 Oct 87 21:50 EDT
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <272@usl>
Newsgroups: comp.os.minix
Date: 30 Sep 87 20:33:39 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
Comments: Warning -- RSCS tag indicates an origin of SMTP@WISCVM
From: Eric Lee Green <ELG@USL>
Subject: Re: yacc and/or lex for minix?
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
in article <477@bms-at.UUCP>, stuart@bms-at.UUCP (Stuart D. Gathman) says:
> The source for 'bison' is available free from GNU (Free Software
> Foundation). Hopefully Austin is suppling binary and the $25 is
> a porting fee, otherwise they are violating the copyleft.
Read the copyleft again. As long as you provide the full source code
(including any porting modifications, which become property of the FSF
and thus come under the terms of the license), as well as the object
code, and do not attempt to prevent any further distribution, the GNU
licensing agreement allows you to charge everything you think the
market will bear. RMS mentions, either in the GNU Manifesto or the
licensing agreement, that there may spring up services which advertise
and duplicate GNU and charge a software fee for doing so, but as long
as they didn't consider GNU software to be proprietary and attempt to
restrict distribution, or remove his copyright notices/license
agreements, that was fine with him...
To recap: The "free" in "Free Software Foundation" means that you are
free to do anything you want with the software, with the understanding
that you must provide full sources (including any modifications), you
cannot in any way attempt to restrict further redistribution, and you
cannot remove FSF's notices.
--
Eric Green elg@usl.CSNET from BEYOND nowhere:
{ihnp4,cbosgd}!killer!elg, P.O. Box 92191, Lafayette, LA 70509
{akgua,killer}!usl!elg "there's someone in my head, but it's not me..."mmdf@udel.UUCP (10/02/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 4218;
Fri, 02 Oct 87 04:47:50 FIN
Received: by NDSUVM1 (Mailer X1.24) id 9490; Thu, 01 Oct 87 21:47:33 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 21:45:32 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ab00543; 1 Oct 87 21:58 EDT
Received: from USENET by Louie.UDEL.EDU id aa00540; 1 Oct 87 21:57 EDT
Keywords: unix sysv cron
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <765@iscuva.ISCS.COM>
Newsgroups: comp.sources.wanted,comp.os.minix
Date: 1 Oct 87 01:38:21 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: Rick Schaeffer <ricks@iscuva.iscs.com>
Subject: Looking for PD cron sources
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
I am looking for public domain sources to "cron" or any work-alike
programs. I'm interested in it for minix use...and also for use on
another multi-tasking O/S on which I need to be able to regularly
schedule events. Please reply by email at the address in my signature.
If there are enough "I'm interested too" replies, I will summarize to
these groups.
--
Rick Schaeffer UUCP: uunet!iscuva!ricks
ISC Systems Corp. ricks@iscuva.ISCS.COM
Box TAF-C8 Phone: (509)927-5114
Spokane, WA 99220mmdf@udel.UUCP (10/02/87)
Received: from NDSUVM1(MAILER) by FINHUTC (Mailer X1.25) id 4363;
Fri, 02 Oct 87 05:28:19 FIN
Received: by NDSUVM1 (Mailer X1.24) id 9883; Thu, 01 Oct 87 22:23:31 CDT
Received: from UDEL.EDU by WISCVM.WISC.EDU ; Thu, 01 Oct 87 22:21:16 CDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa00989; 1 Oct 87 22:29 EDT
Received: from USENET by Louie.UDEL.EDU id aa00834; 1 Oct 87 22:22 EDT
ARPA: usenet@udel.EDU, UUCP: ...{harv <usenet@UDEL.EDU>
Source-Info: From (or Sender) name not authenticated.
Message-ID: <87@rocksvax.UUCP>
Newsgroups: comp.os.minix
Date: 1 Oct 87 12:01:20 GMT
Reply-To: INFO-MINIX@UDEL.EDU
Sender: Minix operating system <MINIX-L@NDSUVM1>
From: Marty Leisner <martyl@rocksvax.uucp>
Subject: Controlling processer status -- Minix v. Xinu
X-LSVRepTo:
X-LSVopts: NOACK Org=MINIX-L@NDSUVM1
X-LSVvia: MINIX-L@NDSUVM1
X-LSVTo: info-minix@UDEL.EDU
To: $PEER$ <MINIX-L@FINHUTC>
Minix uses two routines -- lock()/restore() which saves the processor
status in a common private variable (lockvar).
If found this way of coding to often leads to problems when you want to
nest subroutines which each require the interrupts be turned off,
and you don't want to write the code assuming the low-level subroutine is
running with the interrupts turned off.
Xinu uses two subroutines -- disable()/restore(). Disable returns the
processor status and restore gets passed the new processor status -- the
psw should be stored in local memory of the calling function.
I've used variants of the lock/restore/unlock variant for several years and
have gotten bitten too many times than I care to remember. I'm going to
change all references of lock/restore to disable/restore (I just got bitten
again doing some hacking).
Any comments?
Here's the code for disable/restore (real simple):
; disable interrupts and return previous flags setting
procdef disable
pushf
cli
pop ax ; to return to caller
pret
pend disable
; restore processor status as it was
procdef restore, <<proc_status, word>>
push proc_status
popf ; flags are according to proc_status
pret
pend restore
P.S. The above was written using the Aztec assembler (it has a series of
macros which knows how to get at arguments. If arguments are passed in, it
knows to do a
push bp
mov bp,sp
and pret does a
pop bp
only if bp was pushed).
marty
--
marty leisner
xerox corp
leisner.henr@xerox.com
martyl@rocksvax.uucpLISTSERV%DEARN.BITNET@cunyvm.cuny.edu (1.5o) (09/22/89)
Received: from DFNGATE.BITNET by DEARN.BITNET.DBP.DE (Mailer R2.03B) with BSMTP
id 4762; Thu, 21 Sep 89 19:46:32 ESZ
Received: by DFNGATE (Mailer R2.03) id 7372; Thu, 21 Sep 89 19:45:33 MSZ
Date: Thu, 21 Sep 89 19:47 CET
To: MINIX-L@DEARN.BITNET
From: SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE
Subject: nroff problems
Comments: +++ Changed X.430-Header: +++ x
FROM: "Carsten Schiers"<SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE> x
TO: <MINIX-L@DEARN.BITNET> x
MESSAGE ID: <SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE>;129 x
BODY TYPE: IA5TEXT
Hi there,
I tried to compile nroff as posted by ast. I put the macro in the
directory, I specified in the nroff.h file. I am using MINIX/ST.
Then I started:
# nroff -man nroff.1
and got a:
sig=11 to pid=20 at pc=133a0e
memory fault
I did a chmem =80000 /usr/bin/nroff, but had the same effect.
Any help available from the cracks out there?
CU Carsten.
+-----------------------------+----------------------------------------+
Carsten Schiers University of Hamburg, F.R. of Germany
schiers@ University Hospital Eppendorf
imdm.uke.uni-hamburg.dbp.de Dept. of Computer Science in Medicine
+-----------------------------+----------------------------------------+LISTSERV%DEARN.BITNET@cunyvm.cuny.edu (1.5o) (09/22/89)
Received: from DFNGATE.BITNET by DEARN.BITNET.DBP.DE (Mailer R2.03B) with BSMTP id 5106; Thu, 21 Sep 89 19:52:45 ESZ Received: by DFNGATE (Mailer R2.03) id 7379; Thu, 21 Sep 89 19:51:45 MSZ Date: Thu, 21 Sep 89 19:54 CET To: MINIX-L@DEARN.BITNET From: SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE Subject: Help me please... Comments: +++ Changed X.430-Header: +++ x FROM: "Carsten Schiers"<SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE> x TO: <MINIX-L@DEARN.BITNET> x MESSAGE ID: <SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE>;130 x BODY TYPE: IA5TEXT Hi there, I had a recent posting about problems finding ELLE and using RS232 on the ST, but had no response. If someone knows, whether the RS232 patches for MINIX/ST kills any write-access to floppy disc, or where I can retrieve ELLE by non-ftp, I would be glad. Thanks again, CU Carsten. +-----------------------------+----------------------------------------+ Carsten Schiers University of Hamburg, F.R. of Germany schiers@ University Hospital Eppendorf imdm.uke.uni-hamburg.dbp.de Dept. of Computer Science in Medicine +-----------------------------+----------------------------------------+
LISTSERV%DEARN.BITNET@cunyvm.cuny.edu (1.5o) (09/22/89)
Received: from DFNGATE.BITNET by DEARN.BITNET.DBP.DE (Mailer R2.03B) with BSMTP id 8510; Thu, 21 Sep 89 22:07:14 ESZ Received: by DFNGATE (Mailer R2.03) id 7432; Thu, 21 Sep 89 22:06:13 MSZ Date: Thu, 21 Sep 89 22:08 CET To: MINIX-L@DEARN.BITNET From: SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE Subject: Re:nroff problems Comments: +++ Changed X.430-Header: +++ x FROM: "Carsten Schiers"<SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE> x TO: <MINIX-L@DEARN.BITNET> x MESSAGE ID: <SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE>;134 x BODY TYPE: IA5TEXT Hi there, in a recent article I wrote: >I tried to compile nroff as posted by ast. I put the macro in the >directory, I specified in the nroff.h file. I am using MINIX/ST. >Then I started: > > # nroff -man nroff.1 > >and got a: > > sig=11 to pid=20 at pc=133a0e > memory fault > >I did a chmem =80000 /usr/bin/nroff, but had the same effect. Sorry for that, I now read the bug report from Chris about the initialisation to NULL in nroff1.c, and it seems, that this is a problem in the ST implementation. CU Carsten. +-----------------------------+----------------------------------------+ Carsten Schiers University of Hamburg, F.R. of Germany schiers@ University Hospital Eppendorf imdm.uke.uni-hamburg.dbp.de Dept. of Computer Science in Medicine +-----------------------------+----------------------------------------+
LISTSERV%DEARN.BITNET@cunyvm.cuny.edu (1.5o) (09/26/89)
Received: from DFNGATE.BITNET by DEARN.BITNET.DBP.DE (Mailer R2.03B) with BSMTP id 2961; Mon, 25 Sep 89 22:24:44 MEZ Received: by DFNGATE (Mailer R2.03) id 0665; Mon, 25 Sep 89 22:24:18 MSZ Date: Mon, 25 Sep 89 22:26 CET To: MINIX-L@DEARN.BITNET From: SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE Subject: Re: Need a patch for Minix/ST 1.1 Comments: +++ Changed X.430-Header: +++ x TO: <MINIX-L@DEARN.BITNET> x FROM: "Carsten Schiers"<SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE> x MESSAGE ID: <SCHIERS@IMDM.UKE.UNI-HAMBURG.DBP.DE>;169 x BODY TYPE: IA5TEXT In a recent article sandy47@UCSCO.UCSC.EDU writes: >... I have read a multitude of repeated cycles of the >same questions, mostly from new users like myself. I have also seen the many >responses from experts which are of a derisive nature toward these questions. As being a new user for myself, and asking well-known questions various times, I never ever got a derisive answer. Sometimes, I got nothing, but normaly, there was someone, who told me what I wanted to know. >...Level orient- >ation seems like the better approach, since the new users would not then be >interfering with the net bandwidth of the experts. Questions which are have >been repeated a number of times could be dealt with easily since that is why >the group was formed. >... >How about some useful debate on the problems that have been troubling us all: > > comp.os.minix.pc > comp.os.minix.st > > > comp.os.minix.new > comp.os.minix.exp But what if all that derisive experts won't read the comp.minix.newcommers...? >...(If you want to make a personal comment, send it to me by email, >don't post it here.) Sorry for that, but I think that this is a discussion forum. In some other article HC Johnson <hcj@LZAZ.ATT.COM> writes: >I have previously posted a complete MINIX Kernel. >I and others have surely added to the MINIX ST functionallity. >Unfortunately, I would not call the resulting product "real, usable version" >and we have tried. It is a good teaching tool. So this is the time, to thank you and all the others for it. Though it doesn't work on my machine up to now, it has been interessting enough to try it. And this is it, what I am doing it for. +-----------------------------+----------------------------------------+ Carsten Schiers University of Hamburg, F.R. of Germany schiers@ University Hospital Eppendorf imdm.uke.uni-hamburg.dbp.de Dept. of Computer Science in Medicine +-----------------------------+----------------------------------------+