pmacdona@sol.UVic.CA (Peter MacDonald)
quoted text
> Thus I am proposing to look at demand paging from the file system.
> If Linus agrees to consider adding it to linux when it is done, 
> and nobody successfully shoots this proposal down, I will start 
> tuit suite.
> Proposed Design:
> 
>    Phase 1:
>	[deleted]

You don't start small, do you :-).  If I /agree/ to add it to linux? If
anybody implementes paging, he's going to get 2 extra copies of linux
for free.  How's that for an offer?

Seriously, adding demand-loading should be relatively easy.  I wouldn't
suggest going past the filesystem, even for saving the block-numbers
somewhere (and a bit-map won't do it, block nr must be ordered).  Having
the inode-pointer in the process table entry (and not releasing it
before an exit), and using that to find the blocks wouldn't be too hard. 
A bit slower, but conceptually much easier.  Then you can use the
routines already on hand (map() etc). 

Note that the "relatively easy" must be taken with a bit of salt: you
have to add the routines to the paging unit etc etc. No major problems
at least. Also I'd like to keep linux simple even at the cost of some
speed hit, as otherwise it grows until nobody really understands it. I'm
kinda proud of my mm: it's not many lines of code (although it's not
very clear code.)

Re: sticky bits, shared text...

I don't like sticky bits (in the meaning that they lock something into
memory). I doubt it's really that useful on a small machine, that is
essentially single-user. It's easy to grow the cache to 6M or more if
you have the memory, and currently I don't see much unnecessary disk I/O
in a heavy 'make'. Besides - sticky bits are hard to keep track of.

Shared text and sticky bits have another shared problem: right now
linux allows writes to the code segment. This isn't a very big problem,
as the changes to 'mm' are minimal, but you'd have to check that the
code segment is a multiple of 4096 (I /think/ I made ld do this, but I'm
not sure).

The biggest problem however is the amount of data you have to keep track
of.  You'll have to add a lot of structures to know which pages are in
which executable etc.  I don't think it's worth it, especially if real
paging (with a partition of it's own) is implemented. 

tytso@ATHENA.MIT.EDU (Theodore Ts'o):
quoted text
> 
> >9k    : size of minix executable of diff
> >36k   : size of gcc compiled executable of diff
> >4k    : size of gcc compiled diff.o
> 
> >It won't be to long before my disk flow'th over. Not to mention
> >ram requirments.  
> 
> The culprit here is the floating point library (i.e., the soft floats);
> even if your program isn't using floats, printf() drags large portions
> of it in.  The bottom line is that every integer-only executable will be
> roughly 10-20k bigger than it has to be.  That's most of the problem,
> anyway; the most of the rest of it is due to things like gmalloc.o,
> which is 4979 bytes.  (malloc.o on the vax is 1176 bytes).

Yes.  The right way to do this is to add an floating-point emulator in
the kernel, even if shared libraries are added.  This is a real b**ch. 
I'll probably take a look at the djgpp package, but I'd really rather do
it myself (it's an interesting project).  I don't really have the time
though, so ... 

quoted text
> [bug in waitpid]

Yes, I got the fix, but for once I had the bug corrected already. Very
silly thing that came into the system with the "great reordering", when
I changed the process tables. Luckily it isn't very bad. Another related
bug was in crts.o, which always exits with a code of zero if main exits
with a return xx.

John T Kohl <jtkohl@cs.berkeley.edu>
quoted text
> [486/33 bootup problem]
> 
> When I toggle the turbo on & off while running, I don't observe any
> change in running times of programs (but I can discern differences under
> MS-DOS 5.0), even when I run programs which try to time themselves.

This would suggest to me that you have one of those braindead "slowdown"
devices which aren't really completely hardware, but due to some
software solution.  At least some Gateway-2000's had this, which meant
that they couldn't run well in protected mode under windows either
(while accessing floppies or something like that). I don't really know
what to do about it, as I don't know the hardware enough (I've leart a
lot about PC's in the 11 months I've had one, but still...)

I assume linux is running at full speed all the time?

nicholas@cs.uwa.oz.au (Nicholas Yue)
quoted text
> G'day,
>   I had a similar observation when using the 386/387 assembly. I had wanted
> a mathlib badly so I made try to compile the code from DJ's GPP (for MS-DOS).
> The maths routine are written mostly in assembly language. I compiled the
> C and assembly code and made libm.a, ranlib the things. All without problem.
>   I then proceeded to write a small C program with a sin() and tan() call.
> That is when I had
> 
> device not available: 0000
> EIP:    000f:00000060
> EFLAGS: 00010246
> ESP:    0017:03FFFED0
> fs: 0010
> base: 10000000. limit: 04000000
> Stack: 00000044  66666666 40026666 03fffe48
> Pid: 2123, process nr: 4
> dd 44 24 04 d9 fe df e0 9e 7b

This should happen only on a 386-system with no 387. "dd 44..." is some
math instruction (fld? whatever). However, linux depends on the BIOS to
set the %cr0 bits for a coprocessor, and doesn't test for one itself, so
even with 387 you might get this error if you BIOS doesn't set it up
correctly. 

If you have a 387 but this error still happens, contact me, I guess I'll
have to add the test-routine to linux.

		Linus

PS. I now have a kernel that senses the video card (thanks to Galen
Hunt), and the current version of fsck tries to correct things. I'm
working on a "mkfs" that also senses bad blocks, as bad blocks have
wreaked havoc on at least one drive (instant mess). I have a simple
"fdisk" which doesn't try to change the partition tables, but at least
it tells which devices you can use. Anything else that would ease the
installation?