tytso@ATHENA.MIT.EDU (Theodore Ts'o):
quoted text
> 
> Did you mean implementing a 387/487 emulator, or something specific for
> the gcc soft-float routines? ...

Real emulation.

quoted text
>			... I was wondering what sort of speed hit you
> would take (in either case) if each floating point operation required a
> trap to the kernel.  That's why my previous suggestion had suggested
> mapping certain pages into the processes address space, so that the
> calling the FP routines wouldn't require a context switch.

System calls under linux never require a context switch. In fact context
switches are extremely rare: they happen ONLY when one process stops
running and another one starts. The floating point exceptions would be
slow, but that's mainly because they would have to decode the effective
addresses etc.. Not very much fun, but somewhat interesting.

Still, there are a lot of reasons to have a FP-emulator in the kernel.
If somebody wants fast floating point, he'd better get a 387, but I'd
like to be able to support all programs on all machines independent of
the 387. Currently the library is soft-float, which means that you
cannot reliably use it with a program that has been compiled with
"-m80387". Big drawback, as is the possibility that someone has a
program that uses the 387, and half the beta-testers cannot use it..

quoted text
> I was thinking, however, that another, possibly more elegant solution
> would be to assign shared libraries (including the FP routines) to a
> segment which would be visible to all processes.  Then all the stub
> routines would need to do is to do a far call to a predefined segment.
> What do people think?

This is the preferred solution: it's simple and easy to add to the
kernel. The routines in libc.a would just be stubs calling the "library
segment". No problem, except for the math's.

Also, I don't find the math-instructions that time-critical: they are
relatively few in most programs. If you do number-crunching, you have a
387 anyway (as they are quite inexpensive nowadays - I got one just to
be able to test the kernel routines).

Ari Lemmke <arl@sauna.cs.hut.fi>:
quoted text
> 	lib contain new *.s (sig_restore.s and crt0.s) files,
> 	without those would be hard to create sw to Linux.
> 
> 	bin has some new useful utilities, like kermit.

Kermit has a problem with ^C. I didn't even try to fix this, as I didn't
know if it should be fixed. Anybody know? It traps it nicely, and
exists, but somehow I expected kermit to ignore ^C when in terminal
mode. Oh well, I ported it so that I could download files, and it works
for that.

pmacdona@sol.UVic.CA (Peter MacDonald):
quoted text
> Now that I have my hard drive set up, I keep getting protection 
> violations.  It mostly happens when using gcc.  It is along the
> lines of:
> 
> protection violation: 0000
> 
> The hex dump at the bottom is often different.  Like ls began with "c3 ".
> 
> But this also happens when I boot up sometimes.  Or use ls.  But
> then other commands like em work.  I have no 80387.

It's not the lack of a 80387 (and don't get a 287, I'm not sure I can
support it... working on it). It seems more like a corrupted filesystem,
but I have been known to be wrong (sometimes ;-). I'll post the (new)
fsck with binaries to nic some time today, and they might show up
sometime. Still even more beta than the system :-).

The "general protection violation" is a general error: it happens at
most programming errors (or if you try to use minix binaries, or if the
executable file is corrupted). You can see where it happens by looking
at the EIP:-line EIP: segm:address. segm =0008 means kernel problem,
segm=0017 means it happened in the user program. Note that kernel
problems don't necessarily mean that the bug was in the kernel: it might
be a user program that gave a bad pointer to a system-call.

Indeed pgv is so general that it might be anything: a unexpected
interrupt (but they should be trapped, so this isn't that probable) or
something like that...

Wolfgang Thiel <UPSYF173@DBIUNI11.BITNET>:
quoted text
> Hi,
>    which include files should be used? The ones in include.tar.Z or
> those in the kernel/mm/fs .tar file?
>                                     Wolfgang

I use the ones in include.tar.Z, but they should really be identical.
This isn't absolutely true, but if there are differences, they should be
minimal. I'll have to consolidate them (no big problem now when I have
no minix include-files I can mess up with).

Bruce Evans <bde@runx.oz.au>:
quoted text
> 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.

Oh, shared test works fine after a fork (try running 10-20 bashes inside
each other), but not when executing a new program that already is in
memory. It should be easy to check for (especially once demand-loading
is in place), so this too will eventually be implemented (so that bash
doesn't have to be loaded completely if it is executed from within some
other program).

		Linus (torvalds@kruuna.helsinki.fi)

PS.  Small bug-report: signals weren't correctly reported as the cause
for exiting, but they are now (in my version).  287-coprocessors weren't
noticed at all (this was the problem with nicholas), and I'm not sure
the code uses them correctly now either, but at least it tries...
Coprocessor errors now correctly cause a SIGFPE, no longer the debugging
info. Likewise "not-present" errors.

Also, variable speed serial connections are now implemented, and seem to
work (testing from kermit). Direct reads/writes to a >64M partition
should also work now (thanks to who-ever. My mind is going... )