[1074] in SIPB_Linux_Development
No subject found in mail header
daemon@ATHENA.MIT.EDU (jered@MIT.EDU)
Wed Oct 4 23:07:50 1995
From: jered@MIT.EDU
Date: Wed, 4 Oct 1995 23:07:29 -0400
To: linux-dev@MIT.EDU
To: linux-dev@mit.edu
Subject: ELF migration
It's about time ELF migration got into full swing. I have a few reasons
for reaching that conclusion: Slackware 3.0 ELF was just released, Sal
is about to release the Linux/Athena packages compiled as ELF, Derek
is going to work on AFS/ELF RSN, RedHat 2.0 was released, MATLAB is ELF only,
gcc 2.7.0 is currently only built for ELF, and I'm feeling un-lame about
Linux support. There are essentially two parts to the ELF migration,
getting Linux users to update their machine so that it can run ELF binaries,
and building/installing ELF binaries for Linux.
1. Getting Linux Users to Update their Machine (and Making it Easy for Them)
---------------------------------------------------------------------------
Even if it's painlessly simple to upgrade to ELF, we still have to make
Linux users aware of the change. The only (evil) thing I can think of is
to put some wrappers around commonly used programs that say "ELF migration
is underway! Please read /mit/foo/bar/baz!"
>? QUESTION: How can we make users aware of the migration?
In a week or two, I plan to write a short iELF-Migration that describes
what's going on to users, and how to update their system. I also hope to
write a script that can be run as root that will automagically do everything
necessary (as long as the user has AFS.)
>? QUESTION: What's the absolute oldest kernel that can be used with ELF?
I'll send mail to linux-dev when I get something done.
2. Managing Linux ELF Binaries on Athena
---------------------------------------
I feel somewhat strongly that we should not FORCE users to switch to ELF.
We should not delete a.out binaries and replace them with ELF binaries in
current locations. However, we should ENCOURAGE users to swtich by not
providing any new a.out binaries. But, we should also provide ELF versions
of programs that are currently installed with a.out binaries. This could
possibly be done with lots of wrapper scripts, but would be extrememly ugly,
and IMHO just bad. The other option is potentially worse: A new AFS sysname.
(i386_linuxelf1, most likely. Ugh, that's large.) The ELF version of AFS
would use this sysname. (This guarantees that only ELF systems would use that
sysname, but doesn't guarantee that all ELF systems would, which is
unfortunate. Until there is an ELF AFS, an a.out version could be built
with this sysname, and only ELF Linux users should use it.)
ELF binaries would then go in arch/i386_linuxelf1/bin. This would be a
pain, however. Many, many lockers would need to be updated, and to be able
to use the a.out binaries lots of symlinks would need to be added. However,
there's an (even worse) solution to this. I don't quite understand this,
but Sam tells me that AFS could be made to look at both i386_linuxelf1,
and i386_linux1. (He also said that this could possibly be done by a
seperate LKM, which is slightly better.) This would essentially solve all
of our ELF problems, and both a.out and ELF users would live happily ever
after.
>? QUESTION: What do people think of adding a new AFS sysname?
>? QUESTION: If it's a bad idea, how should ELF binaries be handled?
>? QUESTION: What do people think of the AFS dual-sysname kludge?
Do you have any better ideas?
3. Completely Unrelated Stuff
----------------------------
When I get a chance (in a week or so) I plan on looking at RedHat
2.0 as an alternative to Slackware for Linux-Athena. I'll let you
know what happens.
We should really push UMSDOS to users. Sure, it's a slower
filesystem, but it's a big advantage over NetBSD-Athena....many users
really don't want to repartition their hard drive, or can't for
some reason or another. Perhaps the installation sheet should mention
and explain UMSDOS. Also, the Linux installation documentation that
we have is rather abysmal, and probably should be updated. We're
still handing out last IAP's slides as references. Which brings me
to:
It's IAP planning month. There's a Linux class during IAP. Some
people should probably start looking at revising and expanding upon
last year's materials. We might want to look at getting an LSC slide
at some point in the future. At the very least, we should keep in
mind that IAP will be upon us in a while.
Comments to me and/or linux-dev, flames to /dev/null, and I'd like
to start doing things in a timely fashion, so keep that in mind.
--Jered
