From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 00:53:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2684" "Tue" "1" "December" "1992" "00:49:13" "+0200"
"hlu@eecs.wsu.edu" "hlu@eecs.wsu.edu" nil "90"
"Re: Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA27486
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 00:51:48 +0159
Received: from joker.cs.hut.fi by niksula.hut.fi id <62952-3>;
Tue, 1 Dec 1992 00:51:27 +0200
Received: from dns1.eecs.wsu.edu ([134.121.64.1]) by niksula.hut.fi
with SMTP id <62755-2>; Tue, 1 Dec 1992 00:50:33 +0200
Received: from dori.coea.wsu.edu by dns1.eecs.wsu.edu (16.6/5.910402)
id AA25050; Mon, 30 Nov 92 14:49:51 -0800
Received: by dori (5.57/2.3-EECS.WSU)
id AA07612; Mon, 30 Nov 92 14:49:43 -0800
Message-Id: <9211302249.AA07612@dori>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211301905.AA14760@sunlight.Stanford.EDU>;
from "bir7@leland.Stanford.EDU" at Nov 30, 92 11:05 am
X-Mailer: ELM [version 2.3 PL11]
From: hlu@eecs.wsu.edu
To: linux-activists@joker.cs.hut.fi
Subject: Re: Actions, pt. 1 (fwd)
Date: Tue, 1 Dec 1992 00:49:13 +0200
Cc: pmacdona@tadpole.bcsc.gov.bc.ca (Peter MacDonald),
jwinstea@jarthur.claremont.edu (Jim Winstead Jr.),
obz@raster.kodak.com (Orest Zborowski),
david@istwok.ods.com (David Engel),
torvalds@kruuna.helsinki.fi (Linus Benedict Torvalds),
linux-activists@joker.cs.hut.fi (Linux activists)
X-Mn-Key: NORMAL
[...]
> Proposal:
>
> 1. Keep all NET binaries in /usr/net, together with master
> copies of the system files and the "netconfig" program.
>
> 2. Have the "netconfig" program copy the system files to
> the /etc/net directory, and have it customize them in
> a full-screen manner (easy :-)
>
> 3. The "netconfig" could optionally create symlinks for all
> binaries to /usr/bin, usr/ucb or even /etc (daemons).
> Also, it should be able to setup symlinks for the system
> files, to allow the running of binaries that expect them
> in /etc.
>
> 4. Keep all NET libraries _separate_ from the libc.a file,
> to allow for easy upgrading. NET should be a completely
> user-installable package, and this includes programming
> support like libraries and header files.
>
The problem is the maximum number of shared images which can be loaded
at the same time is 6. So far we have
1. libc.so.4.x (libc.a, libtermcap, libdbm.a and libcurses.a)
2. libm.so.4.x (libm.a)
3. libX11.so.y.x
4. Xaw.Ven.so.y.x/Xt.Ven.so.y.x
5. libg++.a (reserved)
6. librl.so.x.y
7. libgr.so.x.y
8. libf2c.so.x.y
9. libXpm.so.x.y
As you can see, 6 is not enough. But we can increase it very easily,
Linus? Like like to have separate shared images for libtermcap,
libdbm.a and libcurses.a. Also, I want to separate libinet.a and
librpc.a from libc.a. That will create quite a lot small shared images.
I am not the performance hit. Another issue, If we decide to do this,
we have to recompile everything. It is very hard to keep it compatible
with old scheme. But kernel has changed a lot to warrant such a
dramatic move. Linus can use get rid of those old sys calls, like
old stat stuff, signal, waitpid, ..... BTW, Linus, we can add a few
more fields to statfs () or add a new statvfs (). I'like to see a
t least a new field indicating the maximum length of file name. It is
the very good time to cleanup the kernel. It may be a good idea for
0.99 or 1.0. Here is the hard part. We have to recompile everything and
new kernel and binaries will not be compatible with old ones. I
volunteer to make the followings:
1. ispell 3.09
2. make 3.62
3. textutils
4. fileutils
5. shellutils
6. gnu tar
7. gdb 4.7
8. bash
9. zsh
10. time stuff
11. ldd
12. compress
13. mount
14. simple init/adm
15. diff 2.0
16. grep/fgrep
17. gawk
18. patch
19. bison/flex
20. find
21. elvis
22. sed 1.13
23. uuencode/uudecode
24. mincom/rzsz
25. file
26. LILO 0.6
27. extfs 10.1
I will also make a bootable rootdisk to get everything going since
no old binaries will work under new kernel.
It will be painful for all of us. I think it is worth it.
H.J.
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 01:34:17 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["495" "Tue" "1" "December" "1992" "01:32:50" "+0200"
"tthorn@daimi.aau.dk" "tthorn@daimi.aau.dk" nil "17"
"Re: Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA27563
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 01:34:13 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61812-3>;
Tue, 1 Dec 1992 01:33:50 +0200
Received: from daimi.aau.dk ([130.225.16.1]) by niksula.hut.fi
with SMTP id <62755-3>; Tue, 1 Dec 1992 01:33:18 +0200
Received: from belfort.daimi.aau.dk (sezanne.daimi.aau.dk)
by daimi.aau.dk with SMTP id AA29239
(5.65c8/IDA-1.4.4 for < linux-activists@joker.cs.hut.fi>);
Tue, 1 Dec 1992 00:33:21 +0100
Received: by belfort.daimi.aau.dk (5.64/1.34)
id AA11923; Tue, 1 Dec 92 00:33:18 +0100
Message-Id: <9211302333.AA11923@belfort.daimi.aau.dk>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
References: <9211302249.AA07612@dori>
From: tthorn@daimi.aau.dk
To: linux-activists@joker.cs.hut.fi
Subject: Re: Actions, pt. 1 (fwd)
Date: Tue, 1 Dec 1992 01:32:50 +0200
X-Mn-Key: NORMAL
hlu@eecs.wsu.edu write:
>It will be painful for all of us. I think it is worth it.
Yes, I agree, but think it's unavoidable, and it will properbly
happen again.
Speaking out of ignorance, what is the pros and cons of using
PIC (Positions Indenpendent Code) for shared libraries, and
should it be considered in future?
Is there any sense in considering likely changes to the library,
like if the much-spoken-of shared memory system calls were added?
Just my 0.2 dB of noice...
/Tommy Thorn
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 01:41:30 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["797" "Tue" "1" "December" "1992" "01:40:16" "+0200"
"hlu@eecs.wsu.edu" "hlu@eecs.wsu.edu" nil "32"
"Re: Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA27586
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 01:41:27 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62111-4>;
Tue, 1 Dec 1992 01:41:09 +0200
Received: from dns1.eecs.wsu.edu ([134.121.64.1]) by niksula.hut.fi
with SMTP id <61840-3>; Tue, 1 Dec 1992 01:40:51 +0200
Received: from dori.coea.wsu.edu by dns1.eecs.wsu.edu (16.6/5.910402)
id AA26073; Mon, 30 Nov 92 15:40:48 -0800
Received: by dori (5.57/2.3-EECS.WSU)
id AA07743; Mon, 30 Nov 92 15:40:46 -0800
Message-Id: <9211302340.AA07743@dori>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211302333.AA11923@belfort.daimi.aau.dk>;
from "tthorn@daimi.aau.dk" at Dec 1, 92 1:32 am
X-Mailer: ELM [version 2.3 PL11]
From: hlu@eecs.wsu.edu
To: linux-activists@joker.cs.hut.fi
Subject: Re: Actions, pt. 1 (fwd)
Date: Tue, 1 Dec 1992 01:40:16 +0200
Cc: linux-activists@joker.cs.hut.fi (Linux activists)
X-Mn-Key: NORMAL
>
> hlu@eecs.wsu.edu write:
>
> >It will be painful for all of us. I think it is worth it.
>
> Yes, I agree, but think it's unavoidable, and it will properbly
> happen again.
>
> Speaking out of ignorance, what is the pros and cons of using
> PIC (Positions Indenpendent Code) for shared libraries, and
> should it be considered in future?
We have no tools, as and ld, to support PIC.
>
> Is there any sense in considering likely changes to the library,
> like if the much-spoken-of shared memory system calls were added?
>
> Just my 0.2 dB of noice...
> /Tommy Thorn
>
>
H.J.
--
School of EECS Internet: hlu@eecs.wsu.edu
Washington State University BITNET: 60935893@WSUVM1.BITNET
Pullman, WA 99164 Phone: (509) 335-6470 (O)
USA (509) 334-6315 (H)
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 07:34:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1290" "Tue" "1" "December" "1992" "07:30:06" "+0200"
"Eric Youngdale" "eric@tantalus.nrl.navy.mil " nil "24"
"Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA28589
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 07:34:01 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62668-2>;
Tue, 1 Dec 1992 07:33:24 +0200
Received: from santra.hut.fi ([130.233.224.1]) by niksula.hut.fi
with SMTP id <62554-2>; Tue, 1 Dec 1992 07:18:09 +0200
Received: from v6550c.nrl.navy.mil by santra.hut.fi
(5.65c/8.0/TeKoLa) id AA17670; Tue, 1 Dec 1992 06:30:31 +0200
Received: from tantalus.nrl.navy.mil by V6550C.NRL.NAVY.MIL (MX V2.3) with
SMTP; Mon, 30 Nov 1992 23:27:52 EST
Received: by tantalus.nrl.navy.mil (4.1/SMI-4.1) id AA19716; Tue, 1 Dec 92
00:30:34 EST
Message-Id: <9212010530.AA19716@tantalus.nrl.navy.mil>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: hlu@eecs.wsu.edu's message of Tue, 1 Dec 1992 00:49:13 +0200
<9211302249.AA07612@dori>
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
To: linux-activists@joker.cs.hut.fi
Subject: Actions, pt. 1 (fwd)
Date: Tue, 1 Dec 1992 07:30:06 +0200
Cc: linux-activists@joker.cs.hut.fi, pmacdona@tadpole.bcsc.gov.bc.ca,
jwinstea@jarthur.claremont.edu, obz@raster.kodak.com,
david@istwok.ods.com, torvalds@kruuna.helsinki.fi,
linux-activists@joker.cs.hut.fi
X-Mn-Key: NORMAL
>As you can see, 6 is not enough. But we can increase it very easily,
>Linus? Like like to have separate shared images for libtermcap,
>libdbm.a and libcurses.a. Also, I want to separate libinet.a and
>librpc.a from libc.a. That will create quite a lot small shared images.
>I am not the performance hit. Another issue, If we decide to do this,
>we have to recompile everything. It is very hard to keep it compatible
Oh, shit. What the hell is the point of the jump table library if we
decide to break it before we can even officially release a new version?? There
must be some way that we can put our heads together and come up with a way to
do this without breaking all of the binaries that we have already. I think
that this will be worth it in the long run. If you want to break out libinet
and librpc, why not keep the jumps in the libc jump table and have them jump
off to the real routines in the new shared libraries.
If this turns out to be impossible, then I suggest that the way that we
have been doing things is not good enough, and just twiddling the libraries is
not good enough in the long run, and we may need to reexamine some of the
choices that we have made. Perhaps it is time that someone sat down and
actually made an as and ld that can handle PIC.
-Eric
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 06:59:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2404" "Tue" "1" "December" "1992" "06:49:56" "+0200"
"hlu@eecs.wsu.edu" "hlu@eecs.wsu.edu" nil "56"
"New version of jump table" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA28493
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 06:59:45 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62410-3>;
Tue, 1 Dec 1992 06:59:06 +0200
Received: from dns1.eecs.wsu.edu ([134.121.64.1]) by niksula.hut.fi
with SMTP id <62347-4>; Tue, 1 Dec 1992 06:52:22 +0200
Received: from yardbird.eecs.wsu.edu by dns1.eecs.wsu.edu (16.6/5.910402)
id AA28806; Mon, 30 Nov 92 20:50:30 -0800
Received: by yardbird (5.57/2.3-EECS.WSU)
id AA20337; Mon, 30 Nov 92 20:50:25 -0800
Message-Id: <9212010450.AA20337@yardbird>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9212010530.AA19716@tantalus.nrl.navy.mil>;
from "Eric Youngdale" at Dec 1, 92 12:30 am
X-Mailer: ELM [version 2.3 PL11]
From: hlu@eecs.wsu.edu
To: linux-activists@joker.cs.hut.fi
Subject: New version of jump table
Date: Tue, 1 Dec 1992 06:49:56 +0200
Cc: linux-activists@joker.cs.hut.fi (Linux activists)
X-Mn-Key: NORMAL
>
>
> >As you can see, 6 is not enough. But we can increase it very easily,
> >Linus? Like like to have separate shared images for libtermcap,
> >libdbm.a and libcurses.a. Also, I want to separate libinet.a and
> >librpc.a from libc.a. That will create quite a lot small shared images.
> >I am not the performance hit. Another issue, If we decide to do this,
> >we have to recompile everything. It is very hard to keep it compatible
>
> Oh, shit. What the hell is the point of the jump table library if we
> decide to break it before we can even officially release a new version?? There
> must be some way that we can put our heads together and come up with a way to
> do this without breaking all of the binaries that we have already. I think
> that this will be worth it in the long run. If you want to break out libinet
> and librpc, why not keep the jumps in the libc jump table and have them jump
> off to the real routines in the new shared libraries.
>
I have a way to do just this. But I think it is kind of messy. Now you
asked :-):
1. Separate librpc.a, libinet.a from libc.a as suggested. Make the separate
shared images for them. Everthing is done the normal way.
2. Here is the trick part. When build the jump table for the new libc.so.x.y,
I will redirect all the calls to the functions which are not in libc.so.x.y
to an special function. That function will load the appropriate shared image
and call the real function in that shared image. We may even call it
"demand loading shared image" :-).
Very messy? It should work for old bianries with one more level of
indirection. All the new binaries will work normally without going
through this messy stuff.
> If this turns out to be impossible, then I suggest that the way that we
> have been doing things is not good enough, and just twiddling the libraries is
> not good enough in the long run, and we may need to reexamine some of the
> choices that we have made. Perhaps it is time that someone sat down and
> actually made an as and ld that can handle PIC.
>
Please contact Ken Raeburn (raeburn@cygnus.com), who is in charge of gas.
He told me he would add PIC to gas in the future.
H.J.
--
School of EECS Internet: hlu@eecs.wsu.edu
Washington State University BITNET: 60935893@WSUVM1.BITNET
Pullman, WA 99164 Phone: (509) 335-6470 (O)
USA (509) 334-6315 (H)
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 16:57:03 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1607" "Tue" "1" "December" "1992" "18:00:01" "+0200"
"Eric Youngdale" "eric@tantalus.nrl.navy.mil " nil "34"
"New version of jump table" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA02963
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 16:57:00 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61463-1>;
Tue, 1 Dec 1992 16:56:37 +0200
Received: from V6550C.NRL.NAVY.MIL ([128.60.11.7]) by niksula.hut.fi
with SMTP id <61461-4>; Tue, 1 Dec 1992 16:56:21 +0200
Received: from tantalus.nrl.navy.mil by V6550C.NRL.NAVY.MIL (MX V2.3) with
SMTP; Tue, 01 Dec 1992 09:57:44 EST
Received: by tantalus.nrl.navy.mil (4.1/SMI-4.1) id AA20354; Tue, 1 Dec 92
11:00:29 EST
Message-Id: <9212011600.AA20354@tantalus.nrl.navy.mil>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: hlu@eecs.wsu.edu's message of Mon, 30 Nov 92 20:50:24 PST
<9212010450.AA20337@yardbird>
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
To: linux-activists@joker.cs.hut.fi
Subject: New version of jump table
Date: Tue, 1 Dec 1992 18:00:01 +0200
Cc: linux-activists@joker.cs.hut.fi
X-Mn-Key: NORMAL
>I have a way to do just this. But I think it is kind of messy. Now you
>asked :-):
>
>1. Separate librpc.a, libinet.a from libc.a as suggested. Make the separate
> shared images for them. Everthing is done the normal way.
Fine. No problem.
>2. Here is the trick part. When build the jump table for the new libc.so.x.y,
> I will redirect all the calls to the functions which are not in libc.so.x.y
> to an special function. That function will load the appropriate shared image
> and call the real function in that shared image. We may even call it
> "demand loading shared image" :-).
I wonder if we really need it to be this complicated. I do not know
what functions are in librpc and libinet, but I would suspect that very few
executables actually use them. Instead of redirecting the calls to the new
location, what if we just put in stubs which basically printed a message and
aborted the image. Those few images that use functions from these libraries
would need to be relinked, but the rest would never know the difference.
Even if there are one or two functions which are commonly used which
come from one of the two libraries, we might maintain a copy of the old
function in libc (done in such a way that when we link a new executable the
linker does not see it).
Other people have suggested that we clean up some of the system calls
(i.e. change the parameter list in some way), and I have no real problem with
this, but we have dealt with this sort of thing in the past without breaking
all kinds of images, and I cannot see any reason why we cannot do this again.
-Eric
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 21:31:38 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["921" "Tue" "1" "December" "1992" "21:28:15" "+0200"
"Theodore Ts'o" "tytso@ATHENA.MIT.EDU " nil "20"
"Re: Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA04257
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 21:31:33 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62347-2>;
Tue, 1 Dec 1992 21:31:16 +0200
Received: from tsx-11.MIT.EDU ([18.172.1.2]) by niksula.hut.fi
with SMTP id <61890-1>; Tue, 1 Dec 1992 21:30:58 +0200
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA11967; Tue, 1 Dec 92 14:28:43 EST
Message-Id: <9212011928.AA11967@tsx-11.MIT.EDU>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: hlu@eecs.wsu.edu's message of Tue, 1 Dec 1992 00:49:13 +0200,
<9211302249.AA07612@dori>
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: linux-activists@joker.cs.hut.fi
Subject: Re: Actions, pt. 1 (fwd)
Date: Tue, 1 Dec 1992 21:28:15 +0200
Cc: linux-activists@joker.cs.hut.fi, pmacdona@tadpole.bcsc.gov.bc.ca,
jwinstea@jarthur.claremont.edu, obz@raster.kodak.com,
david@istwok.ods.com, torvalds@kruuna.helsinki.fi,
linux-activists@joker.cs.hut.fi
X-Mn-Key: NORMAL
If we decide to make a lot changes to the syscall interface, something
to consider is making the termios structure larger, and including the
BSD 4.4 ibaud and obaud fields.
One important thing to consider is that if we do this, backwards
compatibility should be all-important --- old binaries can not be
allowed to break, although it's probably fair if newly compiled binaries
can only work on 0.99 or 1.0 or later systems. This means doing
allocating a new syscall or ioctl number of the changed function, and
supporting both the new and old numbers for several releases.
Changing the structure of the shared libraries (so that we can have more
than 6) is a bit trickier, but it should be doable --- HJ outlined a
possible way of doing this. Making all these changes will be a fairly
big pain in the tuckus, and it probably makes sense to do as many of
them as possible at once, to get it over with.
- Ted
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 22:03:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1784" "Tue" "1" "December" "1992" "21:57:39" "+0200"
"H.J. Lu" "hlu@yoda.eecs.wsu.edu " nil "50"
"Re: New version of jump table" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA04355
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 22:02:23 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62830-3>;
Tue, 1 Dec 1992 22:01:57 +0200
Received: from yoda.eecs.wsu.edu ([134.121.32.2]) by niksula.hut.fi
with SMTP id <62812-2>; Tue, 1 Dec 1992 21:59:37 +0200
Received: by yoda.eecs.wsu.edu (16.6/1.34)
id AA28695; Tue, 1 Dec 92 11:58:12 -0800
Message-Id: <9212011958.AA28695@yoda.eecs.wsu.edu>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9212011600.AA20354@tantalus.nrl.navy.mil>;
from "Eric Youngdale" at Dec 1, 92 11:00 am
X-Mailer: ELM [version 2.3 PL11]
From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
To: linux-activists@joker.cs.hut.fi
Subject: Re: New version of jump table
Date: Tue, 1 Dec 1992 21:57:39 +0200
Cc: linux-activists@joker.cs.hut.fi (Linux activists),
obz@raster.kodak.com (Orest Zborowski)
X-Mn-Key: NORMAL
>
>
[...]
>
> >2. Here is the trick part. When build the jump table for the new libc.so.x.y,
> > I will redirect all the calls to the functions which are not in libc.so.x.y
> > to an special function. That function will load the appropriate shared image
> > and call the real function in that shared image. We may even call it
> > "demand loading shared image" :-).
>
> I wonder if we really need it to be this complicated. I do not know
> what functions are in librpc and libinet, but I would suspect that very few
> executables actually use them. Instead of redirecting the calls to the new
> location, what if we just put in stubs which basically printed a message and
> aborted the image. Those few images that use functions from these libraries
> would need to be relinked, but the rest would never know the difference.
How about X11? Does it use a lot of inet stuff?
>
> Even if there are one or two functions which are commonly used which
> come from one of the two libraries, we might maintain a copy of the old
> function in libc (done in such a way that when we link a new executable the
> linker does not see it).
>
I can do that, either with my messy way or retain a copy in libc.so.x.y.
> Other people have suggested that we clean up some of the system calls
> (i.e. change the parameter list in some way), and I have no real problem with
> this, but we have dealt with this sort of thing in the past without breaking
> all kinds of images, and I cannot see any reason why we cannot do this again.
>
We can do that.
> -Eric
>
H.J.
--
School of EECS Internet: hlu@eecs.wsu.edu
Washington State University BITNET: 60935893@WSUVM1.BITNET
Pullman, WA 99164 Phone: (509) 335-6470 (O)
USA (509) 334-6315 (H)
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 23:01:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["984" "Tue" "1" "December" "1992" "23:00:16" "+0200"
"hlu@eecs.wsu.edu" "hlu@eecs.wsu.edu" nil "28"
"Re: Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA04584
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 23:01:11 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61580-1>;
Tue, 1 Dec 1992 23:01:02 +0200
Received: from dns1.eecs.wsu.edu ([134.121.64.1]) by niksula.hut.fi
with SMTP id <61461-2>; Tue, 1 Dec 1992 23:00:51 +0200
Received: from yardbird.eecs.wsu.edu by dns1.eecs.wsu.edu (16.6/5.910402)
id AA07063; Tue, 1 Dec 92 13:00:47 -0800
Received: by yardbird (5.57/2.3-EECS.WSU)
id AA21024; Tue, 1 Dec 92 13:00:44 -0800
Message-Id: <9212012100.AA21024@yardbird>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9212011846.AA11291@tadpole.bcsc.gov.bc.ca>;
from "Peter MacDonald" at Dec 1, 92 10:46 am
X-Mailer: ELM [version 2.3 PL11]
From: hlu@eecs.wsu.edu
To: linux-activists@joker.cs.hut.fi
Subject: Re: Actions, pt. 1 (fwd)
Date: Tue, 1 Dec 1992 23:00:16 +0200
Cc: linux-activists@joker.cs.hut.fi (Linux activists)
X-Mn-Key: NORMAL
[...]
>
> I don't think it warrants it unless we are redesigning the shared libs
> schema to use PIC or something that handles global data. Just doing it
> to split up the libs, and to remove a few old system calls is not a very
> appetizing idea to me.
>
> I realize that hlu is working under near impossible conditions trying to
> maintain gcc and the libs given the current constraints, but I think a
> lot of his/our problems would go away if we could solve the jump table
> situation, once and for all.
>
386BSD people are working on PIC. They seem to have done some PIC stuff
with as and ld, which are based on very early GNU versions. Maybe we can
borrow some idea from them. I have no idea how PIC works. Could someone
please point me to some PIC papers?
H.J.
--
School of EECS Internet: hlu@eecs.wsu.edu
Washington State University BITNET: 60935893@WSUVM1.BITNET
Pullman, WA 99164 Phone: (509) 335-6470 (O)
USA (509) 334-6315 (H)
From owner-linux-activists@joker.cs.hut.fi Tue Dec 1 23:42:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["909" "Wed" "2" "December" "1992" "00:44:04" "+0200"
"Eric Youngdale" "eric@tantalus.nrl.navy.mil " nil "19"
"New version of jump table" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA04761
(5.65c8/HUTCS-S 1.4); Tue, 1 Dec 1992 23:40:50 +0159
Received: from joker.cs.hut.fi by niksula.hut.fi id <62030-2>;
Tue, 1 Dec 1992 23:40:40 +0200
Received: from V6550C.NRL.NAVY.MIL ([128.60.11.7]) by niksula.hut.fi
with SMTP id <62557-2>; Tue, 1 Dec 1992 23:40:24 +0200
Received: from tantalus.nrl.navy.mil by V6550C.NRL.NAVY.MIL (MX V2.3) with
SMTP; Tue, 01 Dec 1992 16:41:45 EST
Received: by tantalus.nrl.navy.mil (4.1/SMI-4.1) id AA21773; Tue, 1 Dec 92
17:44:32 EST
Message-Id: <9212012244.AA21773@tantalus.nrl.navy.mil>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: H.J. Lu's message of Tue, 1 Dec 92 11:58:07 PST
<9212011958.AA28695@yoda.eecs.wsu.edu>
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
To: linux-activists@joker.cs.hut.fi
Subject: New version of jump table
Date: Wed, 2 Dec 1992 00:44:04 +0200
Cc: linux-activists@joker.cs.hut.fi, obz@raster.kodak.com
X-Mn-Key: NORMAL
>> I wonder if we really need it to be this complicated. I do not know
>> what functions are in librpc and libinet, but I would suspect that very few
>> executables actually use them. Instead of redirecting the calls to the new
>> location, what if we just put in stubs which basically printed a message and
>> aborted the image. Those few images that use functions from these libraries
>> would need to be relinked, but the rest would never know the difference.
>
>How about X11? Does it use a lot of inet stuff?
Would it be possible to relink the X11 shared libraries to the new
libc, plus the new libinet and librpc so that we do not break any X11 binaries?
The actual code and data for the X11 shared image will not have changed at all,
so in principle all of the functions and data should end up at the same
address, but all of the external linkage is changed to reflect the new reality.
-Eric
From owner-linux-activists@joker.cs.hut.fi Wed Dec 2 02:44:40 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2092" "Wed" "2" "December" "1992" "02:43:26" "+0200"
"Linus Torvalds" "torvalds@cs.Helsinki.FI " nil "70"
"Re: Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA05210
(5.65c8/HUTCS-S 1.4); Wed, 2 Dec 1992 02:44:37 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61468-3>;
Wed, 2 Dec 1992 02:44:19 +0200
Received: from hydra.Helsinki.FI ([128.214.4.29]) by niksula.hut.fi
with SMTP id <61467-1>; Wed, 2 Dec 1992 02:43:57 +0200
Received: by hydra.Helsinki.FI (4.1/SMI-4.1/36)
id AA22405; Wed, 2 Dec 92 02:43:54 +0200
Message-Id: <9212020043.AA22405@hydra.Helsinki.FI>
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
From: torvalds@cs.Helsinki.FI (Linus Torvalds)
To: linux-activists@joker.cs.hut.fi
Subject: Re: Actions, pt. 1 (fwd)
Date: Wed, 2 Dec 1992 02:43:26 +0200
X-Mn-Key: NORMAL
hlu writes:
>
> The problem is the maximum number of shared images which can be loaded
> at the same time is 6. So far we have
>
> 1. libc.so.4.x (libc.a, libtermcap, libdbm.a and libcurses.a)
> 2. libm.so.4.x (libm.a)
> 3. libX11.so.y.x
> 4. Xaw.Ven.so.y.x/Xt.Ven.so.y.x
> 5. libg++.a (reserved)
> 6. librl.so.x.y
> 7. libgr.so.x.y
> 8. libf2c.so.x.y
> 9. libXpm.so.x.y
>
> As you can see, 6 is not enough. But we can increase it very easily,
> Linus?
Done. I changed the MAX_SHARED_LIBS define to 16. I doubt we'll need
more.
> Like like to have separate shared images for libtermcap,
> libdbm.a and libcurses.a. Also, I want to separate libinet.a and
> librpc.a from libc.a. That will create quite a lot small shared images.
> I am not the performance hit. Another issue, If we decide to do this,
> we have to recompile everything. It is very hard to keep it compatible
I dislike the PIC option (not mentioned in the mail I followed up to but
in others): looking at the assembler code generated it seems to be
pretty ugly. The 386 doesn't have many registers to start with, and
using one as a base register (%ebx) doesn't help. Besides, I'm not
convinced it helps - pic helps when the starting address isn't known,
but probably won't make a difference for the linux kind of shared libs.
The obvious way to handle backwards compatibility would be to have stub
routines in the libc.a shared image that look something like this:
void __load_networking_lib(void)
{
static int loaded = 0;
if (loaded)
return;
if (uselib("/lib/libinet.so.4"))
do_error_handling_and_die;
loaded = 1;
}
and then for all the routines that are really in libinet:
__old_netroutine1(xxx)
{
__load_networking_lib();
netroutine1(xxx);
}
__old_netroutine2(xxx)
{
__load_networking_lib();
netroutine2(xxx);
}
The stubs could be removed in the next major jump-table version
(/lib/libc.so.5). The above may not be the fastest way (ie no pointer
folding etc), but it's simple, and most binaries never use the routines
anyway. Shouldn't be too complicated. Hlu?
Linus
From owner-linux-activists@joker.cs.hut.fi Wed Dec 2 17:39:15 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1525" "Wed" "2" "December" "1992" "15:36:22" "+0200"
"Tor Arntsen" "tor@tss.no " nil "33"
"6 shared libraries is not enough. Is 16 enough?" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA09940
(5.65c8/HUTCS-S 1.4); Wed, 2 Dec 1992 17:39:13 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <63400-4>;
Wed, 2 Dec 1992 17:38:52 +0200
Received: from benoni.Uit.No ([129.242.5.254]) by niksula.hut.fi
with SMTP id <63314-1>; Wed, 2 Dec 1992 16:07:14 +0200
Received: from benoni by ppenoni.uit.no with SMTP (PP)
id <12332-0@ppenoni.uit.no>; Wed, 2 Dec 1992 14:38:10 +0000
Received: from unas.tss.no
by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix)
id AAbenoni12328; Wed, 2 Dec 1992 14:38:04 +0100
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA01787;
Wed, 2 Dec 92 14:36:50 +0100
Message-Id: <9212021336.AA01787@unas.tss.no>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
From: tor@tss.no (Tor Arntsen)
To: linux-activists@joker.cs.hut.fi
Subject: 6 shared libraries is not enough. Is 16 enough?
Date: Wed, 2 Dec 1992 15:36:22 +0200
X-Mn-Key: NORMAL
Linus writes:
>Done. I changed the MAX_SHARED_LIBS define to 16. I doubt we'll need
>more.
Hmm.. I'm not so sure if 16 is enough. I guess it will be enough for
'standard' libraries, but shared libraries (jump table version) is also a
very powerful tool in real production. By this I mean that people will
want to use shared libraries in their own production systems for their
own purpose.
As an example I am currently maintaining a real-life system where we just
can't afford to relink everything when we want to install a new version
of a particular piece of the system.
So we are using shared libraries. This is *not* a Un*x system, but it has
jump-table shared libraries similar to the Linux libraries.
We have isolated key functions in their own libraries, so all we need to do
is to stop the (24 hour/day) application for a few minutes (we only have
a few minutes available :-), install the new libraries, and then restart.
This has been a very succesful approach, with other benefits as well.
Now we want to port the whole thing to Unix.. and if I could run a version
on Linux as well, it would be even better.
Well, sorry for the long introduction, the real question is just:
- What constraints are limiting the number of shared libraries that we can
have, and would it be possible to increase the number to for example 40?
Now *that* would be enough for all purposes I think. (but never say never..
:-)
Tor (tor@tss.no) - Linux for everything
From owner-linux-activists@joker.cs.hut.fi Wed Dec 2 20:40:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1052" "Wed" "2" "December" "1992" "20:18:45" "+0200"
"Linus Torvalds" "torvalds@cs.Helsinki.FI " nil "26"
"Re: 6 shared libraries is not enough. Is 16 enough?" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA11005
(5.65c8/HUTCS-S 1.4); Wed, 2 Dec 1992 20:40:08 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62567-1>;
Wed, 2 Dec 1992 20:39:52 +0200
Received: from hydra.Helsinki.FI ([128.214.4.29]) by niksula.hut.fi
with SMTP id <62153-3>; Wed, 2 Dec 1992 20:31:06 +0200
Received: by hydra.Helsinki.FI (4.1/SMI-4.1/36)
id AA19216; Wed, 2 Dec 92 20:19:13 +0200
Message-Id: <9212021819.AA19216@hydra.Helsinki.FI>
In-Reply-To: Tor Arntsen's message as of Dec 2, 15:36
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
From: torvalds@cs.Helsinki.FI (Linus Torvalds)
To: linux-activists@joker.cs.hut.fi
Subject: Re: 6 shared libraries is not enough. Is 16 enough?
Date: Wed, 2 Dec 1992 20:18:45 +0200
X-Mn-Key: NORMAL
Tor Arntsen: "6 shared libraries is not enough. Is 16 enough?" (Dec 2, 15:36):
>
> Linus writes:
> >Done. I changed the MAX_SHARED_LIBS define to 16. I doubt we'll need
> >more.
>
> Hmm.. I'm not so sure if 16 is enough. [ deleted ]
I'll let it stand for now: I doubt 16 will be a major limit for anything
but very special cases.
> Well, sorry for the long introduction, the real question is just:
> - What constraints are limiting the number of shared libraries that we can
> have, and would it be possible to increase the number to for example 40?
> Now *that* would be enough for all purposes I think. (but never say never..
> :-)
Each shared library takes up 16 bytes from the task-structure, which
currently is about 3000 bytes. Linux allocates 4096 bytes (one page)
for it, so it would be no problem to change the 16 to something bigger
(64 or so). Just change the define in < linux/sched.h>, recompile, and
reboot. If the task-struct grows beyond 4096 it needs some more work,
but I'll try to keep it under one page.
Linus
From owner-linux-activists@joker.cs.hut.fi Thu Dec 3 14:22:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2077" "Thu" "3" "December" "1992" "10:17:55" "+0200"
"James Michael Chacon" "probreak@sam.ksu.ksu.edu " nil "67"
"Re: Actions, pt. 1 (fwd)" "^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA16302
(5.65c8/HUTCS-S 1.4); Thu, 3 Dec 1992 14:17:08 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <862936-1>;
Thu, 3 Dec 1992 14:16:40 +0200
Received: from sam.ksu.ksu.edu ([129.130.4.69]) by niksula.hut.fi
with SMTP id <62107-4>; Thu, 3 Dec 1992 11:37:53 +0200
Received: by sam.ksu.ksu.edu (4.1/1.34)
id AA05447; Thu, 3 Dec 92 02:18:24 CST
Message-Id: <9212030818.AA05447@sam.ksu.ksu.edu>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211302249.AA07612@dori>; from "hlu@eecs.wsu.edu" at
Dec 1, 92 12:49 am
X-Mailer: ELM [version 2.3 PL11]
From: probreak@sam.ksu.ksu.edu (James Michael Chacon)
To: linux-activists@joker.cs.hut.fi
Subject: Re: Actions, pt. 1 (fwd)
Date: Thu, 3 Dec 1992 10:17:55 +0200
Cc: pmacdona@tadpole.bcsc.gov.bc.ca, jwinstea@jarthur.claremont.edu,
obz@raster.kodak.com, david@istwok.ods.com,
torvalds@kruuna.helsinki.fi, linux-activists@joker.cs.hut.fi
X-Mn-Key: NORMAL
> As you can see, 6 is not enough. But we can increase it very easily,
> Linus? Like like to have separate shared images for libtermcap,
> libdbm.a and libcurses.a. Also, I want to separate libinet.a and
> librpc.a from libc.a. That will create quite a lot small shared images.
> I am not the performance hit. Another issue, If we decide to do this,
> we have to recompile everything. It is very hard to keep it compatible
> with old scheme. But kernel has changed a lot to warrant such a
> dramatic move. Linus can use get rid of those old sys calls, like
> old stat stuff, signal, waitpid, ..... BTW, Linus, we can add a few
> more fields to statfs () or add a new statvfs (). I'like to see a
> t least a new field indicating the maximum length of file name. It is
> the very good time to cleanup the kernel. It may be a good idea for
> 0.99 or 1.0. Here is the hard part. We have to recompile everything and
> new kernel and binaries will not be compatible with old ones. I
> volunteer to make the followings:
>
> 1. ispell 3.09
> 2. make 3.62
> 3. textutils
> 4. fileutils
> 5. shellutils
> 6. gnu tar
> 7. gdb 4.7
> 8. bash
> 9. zsh
> 10. time stuff
> 11. ldd
> 12. compress
> 13. mount
> 14. simple init/adm
> 15. diff 2.0
> 16. grep/fgrep
> 17. gawk
> 18. patch
> 19. bison/flex
> 20. find
> 21. elvis
> 22. sed 1.13
> 23. uuencode/uudecode
> 24. mincom/rzsz
> 25. file
> 26. LILO 0.6
> 27. extfs 10.1
>
> I will also make a bootable rootdisk to get everything going since
> no old binaries will work under new kernel.
>
> It will be painful for all of us. I think it is worth it.
>
>
> H.J.
>
>
I agree with H.J's original proposal. I for one can recompile anything on
my system. I have done X, gcc, TeX, etc.. Lets get it done now, instead
of cludging around it until we have to do it.
If we have a group of people
work on installing the stuff on their system's first, and then recompile
everything we can release it all in one lump sum. I can and do volunteer
to do any of the big packages that people don't have disk space to do.
James
From owner-linux-activists@joker.cs.hut.fi Thu Dec 3 18:28:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["4311" "Thu" "3" "December" "1992" "17:26:38" "+0200"
"Stephen Tweedie" "sct@dcs.ed.ac.uk" nil "85"
"Linux - v1.0 and standards (was re: Actions, pt. 1 (fwd))"
"^From:" nil nil "12"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA17857
(5.65c8/HUTCS-S 1.4); Thu, 3 Dec 1992 18:28:30 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62875-4>;
Thu, 3 Dec 1992 18:28:11 +0200
Received: from santra.hut.fi ([130.233.224.1]) by niksula.hut.fi
with SMTP id <62346-4>; Thu, 3 Dec 1992 18:24:01 +0200
Received: from AA01957 by santra.hut.fi
(5.65c/8.0/TeKoLa) id AA01957; Thu, 3 Dec 1992 17:39:28 +0200
Received: from stroma.dcs.ed.ac.uk by funet.fi with SMTP (PP)
id <08509-0@funet.fi>; Thu, 3 Dec 1992 17:31:05 +0200
Received: from carna.dcs.ed.ac.uk by dcs.ed.ac.uk id aa08345; 3 Dec 92 15:27 GMT
Message-Id: <18356.9212031527@carna.dcs.ed.ac.uk>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: James Michael Chacon's message of Thu, 3 Dec 1992 10:17:55 +0200
<9212030818.AA05447@sam.ksu.ksu.edu>
From: Stephen Tweedie < sct@dcs.ed.ac.uk>
To: linux-activists@joker.cs.hut.fi
Subject: Linux - v1.0 and standards (was re: Actions, pt. 1 (fwd))
Date: Thu, 3 Dec 1992 17:26:38 +0200
X-Mn-Key: NORMAL
A couple of thoughts for Linuxers out there...
1) There has been talk recently of rebuilding several Linux packages to
settle on new shared library conventions.
2) Linux is GREAT. We should be encouraging its spread and development.
3) With the impending arrival of Linux 1.0, we have a chance to bring
Linux to a much wider audience. Much of that potential audience may
be discouraged unless we can deliver some level of binary
compatibility between Linux releases. This doesn't just mean
compatibility over kernel upgrades; more importantly, we need
conventions which will (as far as reasonably possible) allow binaries
compiled on one person's Linux box to run on anybody else's.
Linux v1.0 seems like a golden opportunity to agree on some of the
niggling differences between different Linux installations, to achieve
even more partability and ease of use.
James Michael Chacon < probreak@edu.ksu.ksu.sam> writes:
>> ... We have to recompile everything and new kernel and binaries will
>> not be compatible with old ones. I volunteer to make the followings:
>>
>> [list of packages...]
>> I will also make a bootable rootdisk to get everything going since
>> no old binaries will work under new kernel.
>> It will be painful for all of us. I think it is worth it.
>> H.J.
> If we have a group of people work on installing the stuff on their
> system's first, and then recompile everything we can release it all in
> one lump sum. I can and do volunteer to do any of the big packages
> that people don't have disk space to do.
If we really want to put the effort into releasing packages as one lump
sum, (and for Linux 1.0 a lot of people will probably want to do so,)
there are a few more things we should consider BEFORE the big releases.
Libraries: Do we adopt other jumplibs as standard? I am thinking in
particular of Rob Hooft's readline and graphics libraries. You
can't distribute binaries widely if others don't have the
libraries, and similarly, there's no point having large numbers
of jump libs around if they don't get used.
Pathnames: I recently downloaded the rcs binaries only to find that
rcsdiff fails on "can't exec /usr/local/bin/diff". WHAT? Every
Unix box I have ever seen has diff in /usr/bin. OK, not wanting
the hassle of recompiling rcs I just popped in a symlink - easy,
but downright messy. I have already got symlinks proliferating
between /var/spool and /usr/spool, and /usr/Tex and
/usr/local/lib/tex, to name but two. I have been bitten in the
past by programs (notably man) wanting /usr/bin/compress or
/bin/compress. Then there's the roff/troff/groff/nroff naming
scheme. And should it be /bin/mount or /etc/mount?
Hard coding pathnames is sometimes unavoidable, so as Linux's
software base grows it is becoming more important to decide what
goes where. Somebody (HJ, maybe?) recently posted a sample
pathname.h file for feedback on some of the more important
pathnames, which is a good start, but we need to agree on more
than this.
Personally, my two pet hates are the TeX and emacs pathnames;
the usual releases on tsx-11 place these in /usr/TeX and
/usr/emacs respectively, rather than /usr/local/lib/{tex,mf} and
/usr/local/emacs like God/Knuth/Stallman intended then to be.
Why do we have to be different to everybody else?
Environment variables: on a related note, certain programs rely on
standard pathnames set up in environment variables. (xdvi being
one of the prime examples; lo and behold, in the absence of
environment vars to the contrary, it looks for fonts in
/usr/local/lib/tex/fonts, and can't find them because they are
in /usr/TeX/... .) If standard Linux packages rely on importing
paths from the environment, there should be a recommended
default environment for Linux distributions.
A little thought and consensus now would go a long way to making Linux a
more friendly system.
Any thoughts?
Cheers,
Stephen Tweedie.
---
Stephen Tweedie < sct@uk.ac.ed.dcs> (Internet: < sct@dcs.ed.ac.uk>)
Department of Computer Science, Edinburgh University, Scotland.
From: Stephen Tweedie < sct@dcs.ed.ac.uk>
Subject: Linux - v1.0 and standards (was re: Actions, pt. 1 (fwd))
Date: Sat, 5 Dec 1992 21:40:57 +0200
>> Libraries: Do we adopt other jumplibs as standard? I am thinking in
>> particular of Rob Hooft's readline and graphics libraries. You
> They have been submitted to Peter MacDonald for inclusion in SLS. I
> hope that can make them `standard'.
Fine, but not everybody has SLS. I started Linuxing before the first
SLS release, so have been catching up manually since then. My point is
that there is nothing documenting these (admittedly minor) installation
details anywhere outside the SLS distribution itself, and I at least
don't have enough disc space to try mirroring SLS on top of my current
installation. SLS is, I agree, one of the best starting points for a
standard Linux environment, so maybe somebody should publish an SLS
manifest giving definitive pathnames and a commitment to preserving
these in future releases (as far as possible).
>> Personally, my two pet hates are the TeX and emacs pathnames;
>> the usual releases on tsx-11 place these in /usr/TeX and
>> /usr/emacs respectively, rather than /usr/local/lib/{tex,mf} and
>> /usr/local/emacs like God/Knuth/Stallman intended then to be.
>> Why do we have to be different to everybody else?
> Please: We had a way-too-long discussion about that a few months ago,
> do not start this again. God/Knuth/Stallman didn't intend it to be
> anywhere, and the packages are build to be anywhere. Please think of
> my VAX where I installed TeX in '$disk2:[hooft.tex]', does that look
> like '/usr/local/lib/tex'? In my opinion (and that of many others) an
> installatiopn should NEVER even LOOK at the /usr/local directory.
OK, I didn't want to ressurect a flame war. I don't really care WHERE
the programs are, as long as I can rely on hardcoded pathnames in
downloaded binaries being compatible with my system. Regarding
/usr/local, one of my points was in fact that the tsx-11 rcs tarfile has
hardcoded pathnames to /usr/local/bin/diff, and I would certainly agree
with you here that diff has no right being in /usr/local.
>> Environment variables: on a related note, certain programs rely on
>> standard pathnames set up in environment variables. (xdvi being
>> one of the prime examples; lo and behold, in the absence of
>> environment vars to the contrary, it looks for fonts in
>> /usr/local/lib/tex/fonts, and can't find them because they are
>> in /usr/TeX/... .) If standard Linux packages rely on importing
>> paths from the environment, there should be a recommended
>> default environment for Linux distributions.
> Just a slightly incompatible version of xdvi.
The incompatibility may be trivial, but it could also be trivially
avoided in the first place.
My whole argument was that although I can cope with these slight
incompatibilities, they DO prevent programs from working unless you can
fix them yourselves. If many of these minor quirks can be removed
painlessly, then Linux will be a much more friendly environment for
those less well versed in the workings of Unix.
---
Stephen Tweedie < sct@uk.ac.ed.dcs> (Internet: < sct@dcs.ed.ac.uk>)
Department of Computer Science, Edinburgh University, Scotland.