From: pmacdona@sanjuan (Peter MacDonald)
Subject: fully broiled ideas
Organization: University of Victoria, Victoria, BC, CANADA
Date: Thu, 23 Apr 92 07:22:56 GMT
Two weeks in the Maui sun, and some half baked ideas are now fully broiled.
Here they are, in no particular order.
I note BSDI is promising binary compatibility with SysV 3.2. I imagine
then that if this happens, 386BSD will eventually follow suit if possible.
Soooo, anyone know if there are any steps that could be taken to move Linux
part way towards it now? Like perhaps, adopting the same system call
interface, if possible? I know that the current shared libraries
interface is incompatible with that goal, but ignore that for the moment.
The primary issue here is to strengthen Unix vis-a-vis other commercial
BTW: has anyone tried the OLEO spreadsheet on tsx yet. Bug reports or
"it works for me" reports would be appreciated.
Is anyone working on a fully automated install program like the one
for SUN and DELL?
I would like to see a layered installation available with perhaps the
1) Just the runtime system
2) Development (includes, kernel source, compiler, yacc, etc)
3) X-windows runtime.
4) X-windows development.
This would hit most of the interest groups, while remembering the
frugel (space conscious) nature that draws us all to systems like Linux.
Please reply to:
if at all.
From: firstname.lastname@example.org (david nugent)
Subject: Re: fully broiled ideas
Date: 24 Apr 92 11:42:38 GMT
pmacdona@sanjuan (Peter MacDonald) writes:
> I note BSDI is promising binary compatibility with SysV 3.2. I imagine
> then that if this happens, 386BSD will eventually follow suit if possible.
> Soooo, anyone know if there are any steps that could be taken to move Linux
> part way towards it now? Like perhaps, adopting the same system call
> interface, if possible?
This isn't technically necessary. The executable type should be
determinable by the a.out header, and it is possible to implement
more than one system call interface concurrently.
Three things needed:
a. a.out header to distinguish between a.out types
b. the "executable type" noted for each process
c. different system call tables for the supported executable types
d. various interface routines to convert between non-native
system calls and native ones, and probably some additional
system calls will need to be implemented
e. probably a whole lot of loose ends which fall out of a-c.
I daresay the kernel would get somewhat more bloated. :-)
I believe both SCO and ISC 386/UNIX's implement something like this
already - or must do. ISC, for example, has both a "sysv" and "posix"
system call interface, and different shared libraries. It doesn't
use the a.out header to distinguish between the types though, but
implements a common __ostype() system call which allows switching
between modes. The crt0p.o (the posix startup code) incorporates a
call to __ostype() to set the posix system call interface, and the
exec call assumes sysv by default.
> I know that the current shared libraries
> interface is incompatible with that goal, but ignore that for the moment.
> The primary issue here is to strengthen Unix vis-a-vis other commercial
> operating systems.
I don't know that binary compatibility is work it, to tell the truth, but
this is very much a "user driven" need. All it would mean is that
some commercial binary only applications can run under Linux, but I
personally don't think that it's worth it. Linux comes with full source
now, and encouraging or supporting other vendors to supply without
sources isn't necessarily within it's scope.
> BTW: has anyone tried the OLEO spreadsheet on tsx yet. Bug reports or
> "it works for me" reports would be appreciated.
Seems to work here, although I haven't used it to any great extent. I
like it a lot better than sc though.
david nugent Public Access Usenet "Only Nixon can go to China"
email@example.com +61-3-792-3507 - ancient Vulcan proverb
3:632/400@fidonet, 58:4100/1@intlnet, 199:4242/5@rainbownet, 33:300/6@admin
PO Box 260, Endeavour Hills, Victoria, Australia, 3802.