[proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)
* Michael Banck (mbanck@debian.org) [030626 08:20]:
> On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote:
> > What does oppose us to make subarchitectures quite more easy than now?
> > (That would also be useful for the AMD Opteron and the like that could
> > use normal i386-code, but can profit from optimized code.)
> Nothing opposes it, we're just missing something: The correct patch.
I would start with a proposal first before writing code. Below is a
draft, comments to it? (I know it doesn't specify every detail. It is
a start, not more nor less, and it should be expanded if acceptable in
general. Also a list of subarchitectures must be created. I'm also
willing to produce code once this or another proposal is accepted.)
DRAFT - Subarchitectures for debian [0.1]
Subarchitectures are an extension to a given architecture that
provides optimized binaries that work only (optimized) on a part of
machines of the whole architecture. For example: Code using the
MMX-extensions can not work on all i386-machines. In this text I will
use architecture_subarchitecture or _subarchitecture in examples if
speaking of a subarchitecture (e.g. i386_i386). This text speaks only
of the debian archive and the user interface at installing packages.
If this proposal is adopted it must be expanded to the packaging tools
of course.
Goal:
The addition of subarchitectures must not break the current archiving
system, but enhance it. On the other hand, it must be easy to use and
most transparent to the users. I assume that most packages need not to
be present in an extra subarchitecture-specified version in the
archive, otherwise it would be useful to make a full new architecture.
control-Files:
The syntax of the control-Files is extended in the following way: The
field "Filename" gives the default file for this package. It must be
able to run on each machine of the given architecture, as tools not
knowing of subarchitectures will use this file. (Of course it might be
neccassary to use the standard emulator provided by debian as
discussed at the moment for i386_i386. And I didn't say "make good
performance". No, it just must run. It might be really very
suboptimal, e.g. using much too much emulation code as in "optimized
for _i686, opcodes from _i586, running on _i386, and opcode emulation
in the default linux kernel by debian".)
It is possible to specify another file for subarchitectures with
"Filename[+-]<subarchitecture>", e.g. Filename-i486. A '-' says: Use
this file exactly for the given subarchitecture. A '+' means: For this
and any 'higher' subarchitecture, unless there is a closer match. '+'
has the advantage of making the control-files a bit smaller, but might
be too unfocussed. So both alternatives are given, and the package
maintainer can choose which one suits better in his case.
Meta-Subarchitectures:
Sometimes it is usefull to put some subarchitectures together again by
a specific criterium like existence of a MMU. For this
meta-subarchitectures can be used.
Creating of new subarchitectures (and exceptions to the said):
If a new subarchitecture is created there are usually no specific
files for it at the beginning. But it is usually suboptimal to start
at the very beginning and the lowest common denominator for the whole
architecture. So at selecting the filename of an old package for a new
subarchitecture the selecting tools uses instead a predefined other
subarchitecture. (As a simple example just imagine Debian is running
on _i286, _i386 and _i486 and we just created new _i486. If a system
using _i486 is installing an old package, the selection tools just
behaves as the system is _i386.) "Old" is a package that gives a
Standards-Version where the given subarchitecture was not defined.
Packages only for parts of the architecture:
Sometimes a package is only usable on specific subarchitectures
because of allowing to manipulate specific things, eg microcode
updates, http://packages.debian.org/microcode.ctl. In this case the
package must not specify the filename-field in the control-file. The
package selection tools must show by default these packages exactly on
the subarchitectures where it provide files. Such a package must make
a Pre-Depend on an dpkg-Version knowing of subarchitectures and such a
package must not be uploaded to woody or any older release, including
security or proposed-updates.
Next steps:
I put this list up on http://home.arcor.de/andreas-barth/subarch.html
and will update this file according to the discussion.
The next steps are to get a decision whether to use subarchitectures
or not, and about the above proposal. As soon as this is done the next
steps are to enhance the archive tools. But step after step.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: