Linus:
quoted text
>Re: sticky bits, shared text...

quoted 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

Shared text helps a lot with recursive commands. I'm surprised linux
doesn't already have it. Fork is most naturally done by sharing text and
making it copy-on-write or no-write.

quoted text
>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.

The cache i/o that you don't see hurts (there should be a LED for it :).
Building the library under Minix-386-cached-text takes 25% longer when
the shell is bash. The overhead is actually for something else - copying
40K data from the cache and zeroing 200K bss. Under another version of
Minix with copy-on-access forks, building the library takes another 10%
longer. There is only slightly less copying because a lot of text gets
copied, and more overhead from page faults.

The other thing that hurts without cached text is that heavily-used programs
will be duplicated in the disk cache and as text. Perhaps mapping the disk
cache to text instead of copying it would be almost as good as managing
text separately.

[big program sizes]
quoted text
>> 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

quoted text
>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. 

You would need a printf-emulator in the kernel :-(. The floating point
emulation itself shouldn't be that big.

quoted text
>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

The djgpp emulator (in 32-bit C) is 14+ times slower than my library
routines (in 32-bit asm) (the emulator in Turbo C++ is only 7 times
slower :-). It takes a large amount of code to the emulation compared
with doing the guts of the library.

quoted text
>John T Kohl <jtkohl@cs.berkeley.edu>
>> [486/33 bootup problem]

quoted text
>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

This doesn't explain why the slow mode worked to boot. Perhaps the fast
mode is done in software ;-). I guess the bug is really in the BIOS+linux
with a hot interrupt.

quoted text
>nicholas@cs.uwa.oz.au (Nicholas Yue)
>>   I then proceeded to write a small C program with a sin() and tan() call.
>>
>> device not available: 0000

quoted text
>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. 

The error seems normal. You are lucky to get it instead of a crash. My
1987 Award BIOS and 1990 AMI BIOS can be relied on to set up the %CR0 bits
_incorrectly_ (Award always clears them, on a machine without an x87).
After booting, AMI on my 486 has set %CR0 to 0x10. The relevant bits are

0x01: MP (Math Present): should be set (WRONG)
0x02: EM (Emulation):    should be clear to use x87/486
                         this is what gives the device not available trap -
                         linux must be setting it
0x04: ET (Extension Type): should be set (always set by 486 h/w so BIOS
                         gets this one right :)
0x08: NE (Numeric Error): 486 s/w should use this to get error reporting
                         via exception 16 instead of the crufty IRQ 13
                         necessary for 286-386/287-387 systems

Perhaps Linus meant the coprocessor bits in the parameter RAM. These had
a reuputation for being unreliable for distinguishing between 287's and
no-coprocessor but I think they are OK for 387's.

Bruce