Subject: Linux-Activists Digest #80
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Fri, 17 Apr 92 06:15:08 EDT

Linux-Activists Digest #80, Volume #2            Fri, 17 Apr 92 06:15:08 EDT

Contents:
  Re: swap ? (A. V. Le Blanc)
  Re: tape drive (Hillel Steinberg)
  AS86 (Rob Coleman)
  Graphics and IPC questions... (Alex C. Liu)
  mtools and messed characters on hard boot   help. (Brian Chojnowski)
  Re: Problems with serial port drivers?? (Jim Burns)
  Re: mtools and messed characters on hard boot   help. (Drew Eckhardt)
  Re: AS86 (Drew Eckhardt)
  virtual consoles/pty's (Joseph Knapka)
  Re: more on my problem(I still haven't got any help) : ) (Linus Benedict Torvalds)
  Re: GCC2.1 (Wonderful !) (Craig Burley)
  problems booting (Richard Alan Brown)

----------------------------------------------------------------------------

From: [email-masked] (A. V. Le Blanc)
Subject: Re: swap ?
Date: 16 Apr 92 15:41:33 GMT

In article <[email-masked]> [email-masked] (P Thomson) writes:
>                mkfs /dev/hda3
>                mkswap /dev/hda3  5400 (block) about 5Mbytes
>
>and this seems to work ok ie no errors or complaints
>
>next I'm trying to edit using ue a 1Mbyte file (for test purposes)
>
> 5 seconds later the the disk drive ( a 91 Mbytes space) starts
>working over time (as expected) but then I get an out of memory 
>message and the system seems to hang

What version of the kernel are you running?  There was a problem
in 0.95a, I believe, which was fixed some time ago.  If this is
a later version, especially if it is 0.95c+, it would be well worth
knowing.

Incidentally, have you given a swapon command?

          swapon /dev/hda3

This is necessary before swap is actually used.  The 'free'
command will tell you whether swap is enabled, and if so, how
much is actually being used.

     -- Owen
     [email-masked]

------------------------------

From: [email-masked] (Hillel Steinberg)
Subject: Re: tape drive
Date: 17 Apr 92 01:35:32 GMT

Good point, I have a COLORADO tape drive, and I use it with a program 
called TAPE.EXE under dos, but it would be great if I could treat it 
as a tape drive - i.e. /dev/rst0 !!!

------------------------------

From: [email-masked] (Rob Coleman)
Subject: AS86
Date: 17 Apr 92 04:02:34 GMT

I'm curious just what is necessary in an assembly source file to create
an executable with either as/ld or as86/ld86.  Maybe a better question
is which is the preferred assembler (if there is one), and what is the
basic format of the file, and method to assemble and link it?  Ultimately,
I will probably just be hacking the assembly portion of the kernel which
doesn't require that I know this, but I'd also like to be able to create
standalone programs.
Thanks..

-- 
        Rob Coleman              ][   Science, like nature, must also be tamed. 
  [email-masked]       ][     With a view towards its presevation..
Georgia Tech, P.O. Box 30449     ][
     Atlanta, GA  30332          ][                  -Rush/Natural Science

------------------------------

From: [email-masked] (Alex C. Liu)
Subject: Graphics and IPC questions...
Date: 16 Apr 1992 21:06:42 -0700

Hi,
   I would like to know if somebody is working on a "standard" way to
access the VGA (or EGA) graphics of the PC trough Linux?  I have a few
ideas on a couple of programs that would required some access to the
screen, but there is no Linux support for video.  And before going in
and adding stuff to the kernel, I would like to know if somebody is
already doing something like that.  I would *assume* that whoever is
working on porting X should be doing something like that. (Is anybody
ACTUALLY working on X for Linus?)  I wouldnt mind doing it myself, but
if somebody is working on it, I would hate to have repeated redundant
efforts.   If you are working on the graphic interface or X would you
please e-mail me?

Also, is there any form of IPC built into Linux?  One of the most
powerful capabilities of a multitasking system is IPC.  But how do you
do it on LInux?  Do they use SysV style IPC (shared mem, msg queues
and semaphores) or do they use berkeley style socket IPC?  (Or
neither) Is somebody working on this?  I saw somebody had an IPC Pipe
library working for v0.12, but no such thing for v0.95c?  Again,
whoever is working on the IPC would you please email me?

And one last question.  Is it possible to add new C system call to the
kernel?  If so how do you do it?  And how do you tell the linker that
this call exits???

Please e-mail, and I will summarize.

-- 
_____________________________________________________________________________
Alejandro Liu           |EMail: [email-masked] |All mispellings are intentional
3131 Mc Clintock #373F  |Voice: 213-745-2431 |Anything mentioned here is not
Los Angeles, CA 90007   |                    |necessarily true.

------------------------------

From: chojnows@osiris (Brian Chojnowski)
Subject: mtools and messed characters on hard boot   help.
Date: 17 Apr 92 03:53:52 GMT

        I have finnaly gotten my hard drive configured to hold both the dos
and Linux OS's invisible to each other. A friend of mine found a neat
utility that let me select f1,f2, etc.. on bootup, which partition to boot
from. I gave up on figuring out how to create a linux only boot partition,
so I wound up making a 3m dos partition, and used bootlin. If anyone knows
how to make Linux boot from the hard drive sans Dos, it would be neat. I
know have 2 problems: 1) I grabbed the binaries for mtools from
tsx-11.mit.edu, and when they are run, I always get the message 'Device not
found -- please specify device' or something like that. What have I not done
to get these to work? and secondly, when booting from floppy, everything
works fine, including the SVGA menu. But from the hard drive, after bootlin
spits out its 3 messages, I get a line of garbage characters. When I press a
key other than enter, it finishes loading in 80x20 mode, hitting return
doesnt give me a menu, I get 80x43 mode. Has anyone else had this problem
after useing bootlin to boot?

        Brian Chojnowski
        -please pardon my grammar, I was in a hurry.

------------------------------

From: [email-masked] (Jim Burns)
Subject: Re: Problems with serial port drivers??
Date: 17 Apr 92 04:12:25 GMT

in article <[email-masked]>, [email-masked] (Drew Eckhardt) says:

>>>You're not *supposed* to be able to do this. The ISA interrupts are level
>>>triggered, which I believe means that after the ICU latches the first

[...]

>>>The MCA interrupts are level triggered, so this is not supposed to be a
>>>problem there.

> 100% false with ISA.  ISA interrupts are edge triggered.  It has nothing

[...]

> You are correct about MCA though - it uses level active IRQ lines,
> and they are open collector. 

Sorry, that was a typo, as you can tell from the contrast in the context.
-- 
BURNS,JIM (returned student)
Georgia Institute of Technology, 30178 Georgia Tech Station,
Atlanta Georgia, 30332            | Internet: [email-masked]
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a

------------------------------

From: [email-masked] (Drew Eckhardt)
Subject: Re: mtools and messed characters on hard boot   help.
Date: Fri, 17 Apr 1992 05:42:56 GMT

In article <[email-masked]> chojnows@osiris (Brian Chojnowski) writes:
>
>       I have finnaly gotten my hard drive configured to hold both the dos
>and Linux OS's invisible to each other. A friend of mine found a neat
>utility that let me select f1,f2, etc.. on bootup, which partition to boot
>from. I gave up on figuring out how to create a linux only boot partition,
>so I wound up making a 3m dos partition, and used bootlin. If anyone knows
>how to make Linux boot from the hard drive sans Dos, it would be neat. I

Shoelace is quite bletcherous, but it does work, and it works reasonably
well once installed.  

Get shoelace.  Install the following files : 
/shoelace (NOTE : THIS MUST BE IN /)
/etc/bootlace 
/etc/winiboot 

and 

/etc/config 
/etc/disktab

Edit the boot line in /etc/config to suit your personal tastes.
/vmunix is a NORMAL name for a kernel, so I boot that.  You can
ignore the other lines, as they concern the building 
of a Minix image, and other minix things.

/etc/disktab

laceup should be in /etc or /usr/etc.

Now, run laceup on your root partition with 

laceup /dev/hd[whatever] wini

This will put a boot block on THAT PARTITION.  If you choose this 
partition as your 'active' partition, this partition will boot up.

Now, you need a program to select your active partition at bootup,
so you don't have to use fdisk or some heinous DOS program to 
select your boot partition.   

winiboot does this.

laceup -w [default boot partition] /dev/hd[wholedevice]  

where wholedevice is the device for the ENTIRE hard disk.

Booting : 
1.  Winiboot will prompt for a partition number to boot, with the 
        default marked with an asterisk.  Hit a number,
        or if it times out, the *'d partition will be 
        booted.  

2.  /shoelace will load.  When this happens, it will either 
        boot the file specified in the boot line,
        or if you space bar it, you can select 
        any other file to boot from.  Use ls  to find what 
        you want, load to run it.  

>know have 2 problems: 1) I grabbed the binaries for mtools from
>tsx-11.mit.edu, and when they are run, I always get the message 'Device not
>found -- please specify device' or something like that. What have I not done

The old mtools utilities used /dev/DosA /dev/DosB and /dev/DosC or 
other equally heinous device names.  Recompile it with your 
preferences.

------------------------------

From: [email-masked] (Drew Eckhardt)
Subject: Re: AS86
Date: Fri, 17 Apr 1992 05:54:51 GMT

In article <[email-masked]> [email-masked] (Rob Coleman) writes:
>I'm curious just what is necessary in an assembly source file to create
>an executable with either as/ld or as86/ld86.  Maybe a better question
>is which is the preferred assembler (if there is one), and what is the
>basic format of the file, and method to assemble and link it?  Ultimately,

as86 and ld86 are used for two files in the kernel source tree, 
boot/setup.S, boot/bootsect.S.  They create 80x86 REAL mode code.

You MUST use gas (as) and gld (ld) for 386 code.  gas uses that AT&T 
syntax, which differs radically from intel syntax.  

Texinfo gas documentation is available from prep.ai.mit.edu under 
the usual /pub/gnu directory, so I won't cover the Intel / AT&T syntax
differences other than saying you need the documentation.

Also, remember that as is designed to read compiler output, not human
generated code, and if you want ANY macro capabilities, use the 
C preprocessor.  Also, when given a .S file, gcc 2.x will run 
cpp on it before passing it to as, and running gcc on a .s file 
will 'do the right thing'

>I will probably just be hacking the assembly portion of the kernel which
>doesn't require that I know this, but I'd also like to be able to create
>standalone programs.
>Thanks..
>

For very small things, that have minimal use of the library functions 
(or only syscalls), you can just make an assembler program, which is 
entered at address zero, and has a call to __exit, assemble it,
and link it to libc.a.  For more substantial things, 
write a 'C' driver, or _main function in assembler 

ie 
.globl main
_main:

and link as a normal 'C' program.  

Interfacing to 'C' is done in the usual way, with parameters pushed 
in reverse order, on a 32 bit wide stack, 32 bit return address, caller
removing parameters.  Naming convention is standard 'C', with all 
global symbols prefixed with an _.  

------------------------------

From: [email-masked] (Joseph Knapka)
Subject: virtual consoles/pty's
Date: 17 Apr 92 06:46:10 GMT

Here's a silly question: When I boot linux, it says "8 virtual
consoles, 4 ptys". I know what ptys are, I think -- the guys I get to
by alt-f[1-4]. So my question is, "What, exactly, is the difference
between a pty and a virtual console?"

Thanks,

------------------------------

From: [email-masked] (Linus Benedict Torvalds)
Crossposted-To: alt.os.linux
Subject: Re: more on my problem(I still haven't got any help) : )
Date: 17 Apr 92 08:03:04 GMT

In article <[email-masked]> [email-masked] writes:
>Ok, here goes:
>I had xcomm, it was running fine.  suddenly, it started outputting to the
>screen 2 cr/lf for every one I hit on the keyboard.  I went into kermit
>to see if it was xcomm, or the place I  am calling.  kermit was doing
>this:
>C-Kermit>set line /dev/ttys4
>
>C-kermit> set speed 2400

At least the double-spacing in kermit is due to login first enabling
ECHONL on the tty for the password recognition (it naturally wants no
echo on normal characters, but wants the newline to be echoed), and it
doesn't disable it afterwards. This doesn't result in any problems for
most things, but some programs (at least my port of kermit) seem not to
notice it: kermit disables echoing, but doesn't disable the ECHONL.

The cure for kermit is to write "stty -echonl" in your .profile or
similar - I don't know if this helps xcomm as well.

                Linus

------------------------------

From: [email-masked] (Craig Burley)
Subject: Re: GCC2.1 (Wonderful !)
Date: 17 Apr 92 07:43:12 GMT

In article <[email-masked]> [email-masked] (John Plevyak) writes:

   As I remember (from long ago) the Primos (the Prime operating system)
   replaced all dynamic calls with calls to illegal addresses.  

Specifically, I believe the linker did the replacing when building a program
image file (EPF or old-style) -- so the file had pointer-faulted references
to dynamic links (remove the "pointer-fault" bit in the pointer and you have
a pointer to a CHAR(*) VARYING string having the name of the routine needed.

   A table in
   the image mapped the index of the illegal address to a filename/symbol
   pair.  The filename was found or loaded and the address was patched.  This
   has the advantage that you could dynamically replace the library without
   relinking (the linker was in the OS).  This could be used on a 386 class
   machine.

Well, you have to make sacrifices to do this on a 386 that you couldn't make
on Prime 50 series machines.  Specifically, all 50 series machines had only
one general format for indirect pointers that imposed the pointer-fault, ring,
and extension bits on all such pointers.

The flat-address model for the 486 allows a task to address all 4 gigabytes
representable by a 32-bit pointer.  In this form, dynamic linking is still
possible but adds an expense to each unsnapped pointer -- unless you reduce
the accessible space to 2GB by allocating one bit as the "fault" bit (so the
unfaulted version points to a string) or some such thing, you need more
memory for each faulted pointer.

The segmented pointers of the 486 (48-bit pointers) offer slightly more
opportunity for providing Prime-style unsnapped pointers without significantly
infringing on the overall accessible space in a program, I think.  For example,
(and I'm just guessing here, after only reading the 486 arch manual once),
two segment numbers could be reserved to "unsnapped pointer to name in CS
seg space" and "unsnapped pointer to name in DS space" or some such thing.

But the lack of an explicit "fault" pointer means 486 OS architects do have
to make a tough choice when deciding on how to provide dynamic linking (the
"true" kind -- it's still quite easy to do the semi-dynamic kind that VMS
does, where all unsnapped pointers are snapped by the OS when an executable
is mapped to memory).

   The disadvantages were:

           1) your program could suddenly fail if the new library (installed by
                   someone else) had a bug

Yes, but it taught most of us Prime OS and library engineers to get our act
together, since even our pet programs would break if we screwed up a new
library install even before we'd relinked the programs!  I.e. this might
really be an advantage overall.  It teaches people to treat library changes
and testing more like they're doing OS work than doing single-program work.

           2) you could not page directly off the executable

Either I misunderstand you or this is wrong.  EPFs were directly paged into
memory as needed (that is, the "text" or code-space portion).  PRIMOS generally
had pointers (especially unsnapped ones) in read/write segments (pointed to
by the Link Base, LB%) along with ECBs (procedure Entry Control Blocks) and
such.  So, normally, changing these things to accommodate the latest placement
of a newly invoked EPF (program/library) didn't require changing pure code,
so that code could be paged in on demand, making startup potentially quite
fast.  Some applications required pointers and ECBs to be placed in pure code
to improve shareability, but naturally this meant things they pointed to had
to be statically placed (typically in system-wide shared and unshared segments
rather than per-user shared/unshared segments), so they don't really count
in this discussion.

Sheesh, it's been a long time since I've thought about this stuff.  If I
screw it up, Kevin Cummings will likely correct me, since he probably knows
far more about it than I do (and as I recall, knew more back when I was still
at Prime)!

           3) your operating system was forced to intervene on  the first of
                   every dynamic call... thus slowing startup time.

Mmm, maybe, I'd say the penalty wasn't so much slower startup time, but
slower execution of newly reached paths with the payoff often being _faster_
startup time.  PRIMOS might not have to even read much of the program in
at all, just some LB%-relative stuff to adjust pointers and ECB link-segment
numbers for the user's particular segment placement.  If the program was
already shared (mapped) via either another user or a recent invocation of
the same program by the same user, that'd be very little time.  It might be
that a comparatively few link-snaps later, the user'd get a useful response
(like a prompt), faster than the old way of having to block-read a monolothic
program entirely into a static place in memory (and with more flexibility than
the latter).

Problem was, if the user issued a command, it might well involve hundreds or
thousands of new link-snaps (dynamic links not yet resolved), so _that_
command's first invocation would be slower than subsequent invocations.

The idea was that amortizing the cost of loading and linking across the
entire execution of the program would often cut down on the need to snap
many links at all, since (particularly for large monolothic apps, like SPSS)
users typically wouldn't invoke all the code in the program per invocation.
So it was actually expected to be practical for a user to frequently invoke
a large monolothic app just to do a quick command or two.  Of course, that
was based on assumptions regarding user interaction that are increasingly
coming into question today for at least some popular application domains.

Still, thinking about designing an OS for the 486 causes me to weigh a lot
of interesting questions, like: should a given task be able to stack
multiple programs in arbitrary places (segments) in its memory space as
PRIMOS permitted (with EPFs but not with old-style static images), given an
OS that permits cheap tasks?  I.e. is the cost of allowing arbitrary placement
of programs in per-task virtual memory worth the benefit, when an alternative
(cheap processes) is available?  Can it be provided in a manner that costs
non-users of the feature very little?  (My guess: no.)

Also, whether to provide access to segments in a 486 OS (instead of the
highly convenient flat-4GB-space model people expect coming from VAXland)
is a sticky question, because _lots_ of people want the flat memory model,
but the segmented model _does_ offer advantages.  Problem: on the 486, the
pointer formats are different, so what does providing _both_ models cost in
terms of the OS interface -- i.e. do you need two sets of OS calls?

   The advantages were:
           1) no need to relink shared library programs
           2) no need to link to libraries that this execution of the program
                   did not require... finer grain linking could be a win here.

I wonder how useful #2 has been in practice in the PRIMOS world.  PRIMOS
provided not just dynamically linked libraries, but statically linked ones
as well (and the PRIMOS entry points essentially belonged in the latter
category).  This meant that any library you expected to be occasionally
invoked for a "quickie" but that was inherently large, you could just make
static in your system, so the only cost was the link-snap cost (name-space
search, snap pointer, continue) but no library-loading cost.

   In general I don't think that you will find an obvious clean and simple winner
   in a war of dynamic linking strategies if you ask more that a few people.

That's for sure.  A lot of the answer depends on the question -- if you want
big monolithic apps that use a variety of big libraries but not necessarily
all of them each time the apps are run, the PRIMOS approach is probably quite
good.  I don't know if most UNIX apps fall into this area; either the apps
are short and sweet (tools, filters, etc) or monolithic with little use of
multiple shared libraries (EMACS comes to mind).

Note that one of the ideas of shared libraries under PRIMOS was that they would
be the primary means for providing services, such as electronic mail, remote
file transfer, queueing, etc.  Under UNIX, these services are typically
provided by separate processes, accessed through IPC via tiny libraries for
apps to just get at the IPC stuff (X follows this model, for example).
Sharing tiny libraries isn't as important as sharing the X server code, which
if you'd talked to the PRIMOS architects back when dynamic linking and
libraries were being designed, would have felt should go into shared
libraries and used shared memory and semaphores to do the display management
and IPC between server tasks.  (I have always felt the server model was better
than the shared-memory model, but couldn't convince the PRIMOS architects
otherwise back when the issue was being decided for most subsystems in
1978/1979.  Nevertheless, the resulting dynamic-linking model seems to be
well-suited for the shared-library-service model, whether or not you like
that latter model.)

Point being that for what "we" want to do in UNIX, and what I am thinking of
doing in my OS research and design, PRIMOS' dynamic linking may provide good
lessons but not necessarily a good model.  It _does_ stretch ones' thought
a bit, though.

   The simplest solution is usually the best though, and (not intending to start
   a war here) while Primos did dynamic linking which was nice, the lack of
   child processes, memory protection of 'shelled' programs, the segmented
   architecture, system calls with a mix PL1/G and FORTRAN interfaces and assorted
   other goodies made me wish for Unix with or without dynamic linking
   (perhaps it has changed, this was 1986).

I last "knew" PRIMOS at rev 19.4 in 1985, which is why I refer to it in the
past tense; I don't know how much it has changed.  I agree with the
disadvantages you cite, except that I am unwilling to categorically state
that segmented architecture is bad (yes, it's hard, but it offers wonderful
optimization opportunities at the hardware/microcode level from what I can
tell, and also offers higher bit-efficiency for instructions in memory; I
don't think these advantages translate well to RISC, however).  The lack of
memory protection between programs in the same task (stacked programs) was
sometimes a pain, but the segmented architecture _itself_ mitigated this
significantly (i.e. programs didn't tend to just run off one segment into
another, because the necessary pointer arithmetic was rarely implemented
except when an array was known to span segments, itself a rare condition,
and in any case getting _contiguous_ arrays wasn't always possible).  So
though it may have happened occasionally, I don't remember having to chase
down any inter-program-stomping bugs like we all do under Mac or DOS or
similar (PC-like) OSes; similarly, the stack being in separate segments (and
separately managed by the OS) also allowed certain bugs to be caught much
earlier than in a typical flat-model OS (though a paging OS can help provide
almost as early detection of stack overflows as did PRIMOS' segmented
model).

Sigh, I _am_ rambling -- must be late, and I must not want to get any real
work done!  :-)
--

James Craig Burley, Software Craftsperson    [email-masked]
Member of the League for Programming Freedom (LPF)

------------------------------

From: [email-masked] (Richard Alan Brown)
Subject: problems booting
Date: 17 Apr 92 09:48:40 GMT

A problem, not from rab@ariel... but it may interest him also.

I used rawrite to make a bootable disk and a rootimage disk. When I 
boot my pc with the floppy in, I get the loading............
and the SVGA mode question. 
when I press any other key, the system simply reboots, and cycles through
this same process.

Hmm.

Its probably obvious, but any ideas what might be going wrong?

alistair scott
[email-masked]

------------------------------

** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [email-masked]

You can send mail to the entire list (and comp.os.linux) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    tupac-amaru.informatik.rwth-aachen.de	pub/msdos/replace

The current version of Linux is 0.95a released on March 17, 1992

End of Linux-Activists Digest
******************************