From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: alt.os.linux
Subject: V86, echo, *P=NULL etc updates
Date: 23 Jan 92 11:25:40 GMT
Organization: University of Helsinki
Replying to questions (mostly from the mailing-list - I'm trying to move
over to alt.os.linux):
> V86-mode and DOS sessions under Linux?
Right. Seems everybody wants these, but the problem is that Linux wasn't
designed with V86-mode in mind, and the memory management makes some
assumptions that are simply incompatible with V86 tasks. The problem is
that a V86-task /has to/ be at virtual address 0-1M, and doesn't care
about the current linux protections scheme that uses segments. All right
so far: but the current kernel also lives in that space. Ooops.
This means that either (1) the mm has to be totally rewritten, (2) we
resort to ugly tricks with changing IDT's and page tables by hand, or
(3) I come up with something clever.
(1) has several problems: the current mm may not be a work of art, but
it /does/ have the good point of working, and it's extremely simple.
Changing the mm to something more like "real" unices would complicate
things. I don't feel this is a good option.
(2) The "ugly" tricks needed are so ugly I'm probably going to have
nightmares just because I thought about them. Trust me: you don't want
DOS compatability that bad.
(3) is of course optimal: the problem is that the I want:
- the first 16 megabytes to be "identity mapped" to the physical
memory. This is one of the reasons the mm is so simple (and there is
no need to translate DMA addresses etc)
- the first megabyte (+64kB) would have to be paged memory for the V86
mode (with all the current frills: demand loading, VM etc).
And these two things don't mix very well. So I thought V86 would have to
wait.
Things aren't really that bad: I brainstormed a little, and I think I've
got the problem solved by using segments and paging at the same time to
make the first 16M /look/ identity mapped, although they aren't. It's
not even going to be very ugly: just a few hacks, that could be said to
be "interesting". I'm not promising anything, though.
> [ echo command ]
No, there is no echo for linux. Not that big a problem: use
#! /bin/sh
echo $*
or port (or write) something in C if you wish. Using a shell-script
isn't that bad: it probably doesn't use much memory, as most of the
pages get to be shared.
> I get "*P=NULL" printed on the console.
Right. This is a debugging message: the sleep-function changed
behaviour in 0.12, and I added a few sanity checks. This message just
means that something is sleeping/waking up without using the proper
routines: I don't know where this happens, but at least it's harmless.
If you know something that consistently brings up this message, I can
probably track it down. I have seen it once, and didn't notice what
caused it.
> mvdir/rename system call
As already mentioned, it doesn't exist. Yet. I'm coding it right now,
and it will work today on my machine (I think), and by the weekend, I
should be able to send out (minor) kernel patches to get it working for
those that want it. I hope.
> Shared libs
Seem to work. The kernel features are there already (even in the
released 0.12), and pmacdona an I have made some simple scripts/programs
to create shared libraries from the current unshared ones. Small
utility programs usually shrink to half their size, but my guess is that
debugging programs using shared libs will be impossible even when we do
get a debugger. I think the 0.13 root-image will contain the first
"real" use of shared libraries.
> Linux-0.13
I still don't know when this will be out: it depends on several things.
Don't try to get TCP/IP, sockets and X all working in time for it - I
think it's going to be released February (mumble mumble 20?)th, and I'm
totally satisfied if it just adds the higher-level routines for VFS and
minor fixes (faster floppy, rename, one totally unnecessary panic-call
etc) and a init/login (I'll use the simple version available already if
the "real" version doesn't get implemented).
Mail me about anything bigger you have already started on: we'll try to
work something out.
Linus
PS. I still try to reply to all personal mail the same day I get it, but
I know I've missed some (not many though). My mail-box grows by about
30-70 messages per day, so I definitely don't have time to go back and
check them out. Re-mail any questions/suggestions if you don't hear from
me.
From: fischer@iesd.auc.dk (Lars P. Fischer)
Newsgroups: alt.os.linux
Subject: Re: V86, echo, *P=NULL etc updates
Date: 23 Jan 92 19:18:36 GMT
Organization: Mathematics and Computer Science, University of Aalborg
In-Reply-To: torvalds@klaava.Helsinki.FI's message of 23 Jan 92 11:25:40 GMT
This is amazing. I am, for the first time ever, considering bying a
PC (yeah, right), just to run/hack Linux. Good work!
>>>>> "Linus" == Linus Benedict Torvalds (torvalds@klaava.Helsinki.FI)
> Shared libs
Linus> Seem to work. The kernel features are there already (even in the
Linus> released 0.12), and pmacdona an I have made some simple scripts/programs
Linus> to create shared libraries from the current unshared ones. Small
Linus> utility programs usually shrink to half their size,
Shared libs are a real advantage, and one you start having things like
X11 with HUGE libraries, shared libraries is a must. A set of 25
statically linked X11 utilities can eat your disk faster than you'd
ever imagine....
Linus> but my guess is that debugging programs using shared libs will
Linus> be impossible even when we do get a debugger.
Yeah, debugging with shared libs can be a pain. I believe it's
important to have the option of doing a static link, just as you can
compile without optimization if need be. This would probably mean that
you need to copies of every lib - a dynamic and a static - but that's
not too bad. If works like that under SunOS (oops, Solaris-1), and
it's mostly pretty nice. The SunOS system of having shared libs with
version numbers is also a good idea -- makes it possible to update a
library withput messing up programs using the old version.
Keep up the good work!
/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things. -- Calvin
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: alt.os.linux
Subject: shared libs
Date: 23 Jan 92 19:59:46 GMT
Organization: University of Helsinki
In article < FISCHER.92Jan23191836@solsort.iesd.auc.dk> fischer@iesd.auc.dk
(Lars P. Fischer) writes:
> Yeah, debugging with shared libs can be a pain. I believe it's
> important to have the option of doing a static link, just as you can
> compile without optimization if need be.
Yes, the shared libs are optional: change the libc.a and crt0.o files
and you can choose between shared/unshared libs. There weren't even any
changes to the compiler/linker: the shared libs are misusing the linker
a bit, but it works.
> The SunOS system of having shared libs with
>version numbers is also a good idea -- makes it possible to update a
>library withput messing up programs using the old version.
Right. Even this is handled "correctly" in linux: it would be even
better with hardcoded addresses in the shared lib, but that was too much
work, so we settled for version numbers. It's going to be interesting
to see if the linux approach to shared libs even closely resembles
anything else: neither I nor pmacdona had any actual references to how
they "should" be implemented.
Linus
From: mb@smsc.sony.com (Michael Burg)
Newsgroups: alt.os.linux
Subject: Re: V86, echo, *P=NULL etc updates
Date: 23 Jan 92 21:00:23 GMT
Organization: Sony Microsystems Corp, San Jose, CA
In article <1992Jan23.112540.5889@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI
(Linus Benedict Torvalds) writes:
>Replying to questions (mostly from the mailing-list - I'm trying to move
>over to alt.os.linux):
>
>> V86-mode and DOS sessions under Linux?
>
>Right. Seems everybody wants these, but the problem is that Linux wasn't
>designed with V86-mode in mind, and the memory management makes some
>assumptions that are simply incompatible with V86 tasks. The problem is
>that a V86-task /has to/ be at virtual address 0-1M, and doesn't care
>about the current linux protections scheme that uses segments. All right
>so far: but the current kernel also lives in that space. Ooops.
>
A V86-Task doesn't physically have to reside below the 1MB region. The V86
process running _thinks_ it's in the 1MB physical region with real-mode type
segments. From a memory management point of view a V86 task is basicly no
different from any other. The only major difference is that the task
might contains pages which are physically mapped to I/O devices (i.e.
video cards). The pages within a V86 task can be swapped, relocated or
even shared.
In commerical versions of Unix for the PC, the kernel support for V86 is
small compared to the entire package. Selected device drivers provide
additional support so devices can be shared between a V86 task and the
entire system. The major of coding lies with the user process attempting
to simulate the BIOS, selected MS-DOS functions & various I/O ports and memory
locations. (timers, CMOS, interrupt controllers) The kernel provides support
for selected "privilage" instructions such as cli, sti, and the "duality" of
process that is containing a V86 task. The kernel also provides a bigger time
slice for those processes which are V86 ones.
In the case of VPIX, the vpix process has a "duality" to it. Part of the
program is a normal "native" 32-bit task, the other half is a V86 task.
Switching from the native task to the V86 task can be done with a IRET
instruction - (and with a little help from the kernel setting up the TSS
correctly). The V86 task traps back into the kernel or back to
the "native" user process depending on the instructions attempted inside
the V86 task.
Intel has a system writer's book which contains a chapter on V86 support.
Michael Burg @ Sony Microsystems, San Jose CA Phone: (408) 944-4032
E-Mail: mb@smsc.sony.com or ..!{uunet,mips}!sonyusa!mb
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: alt.os.linux
Subject: Re: V86, echo, *P=NULL etc updates
Date: 24 Jan 92 11:37:09 GMT
Organization: University of Helsinki
In article <1992Jan23.210023.4021@smsc.sony.com> mb@smsc.sony.com (Michael Burg)
writes:
>
>A V86-Task doesn't physically have to reside below the 1MB region.
No, but it /does/ have to be at VIRTUAL address 0. Thus it IS a special
task: all other linux tasks are given 64M slices of the 4GB address
space, and can use segments to keep them off each others (and make them
beleive they are at address 0). Not so a V86 task. Other unices
haven't got this problem, as they use a flat 32-bit address space, and
change page tables when they change tasks: linux doesn't. This has some
problems, but I'm willing to bet that linux has the simplest mm of any
unix that implementes paging/sharing/demand-loading/VM on a 386. And
frankly, simplicity is the name of the game when you try to implement a
kernel from scratch.
I like the 386 chip (but x86, x<3 are pure sh*t, gimme 68k any day), but
there are two problems with it: write-protected pages are ignored in
kernel mode (corrected in the 486), and V86 cannot be relocated to an
arbitrary virtual address. That's ok if you use only paging to
implement memory management, but frankly, I'd like to see something
where V86 can live /inside/ a 386-segment. Remember: linux isn't really
unix: it's a operating system I wrote with the unix API in mind, and I
didn't do it the same way everybody else did.
Linus