+++ Manuel A. Fernandez Montecelo [2015-09-29 22:14 +0100]:
> 2015-09-29 17:38 Wookey:
> >+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]:
> >>
> >>Maybe it would be a good idea to split the architectures, and have one
> >>port for legacy-but-still-sold-or-useful i386 and move the current i386
> >>to only support newer, common-use i686 hardware.
> >
> >It seems to me that this relates to a similar issue with armel, and
> >previous consideration of 'partial architectures' for mips (and arm).
> >
> >[...]
> >Having a mechanism for 'partial architectures' to keep only the
> >relevant subset of the archive available for these machines seems like
> >a good plan, useful for at least i386 and armel, and probably
> >others. Because a debian arch refers to an ABI, not an ISA-variant,
> >you can't easily use our existing architectures mechanism to have both
> >'i386' and 'i686' without breaking some fairly fundamental assumptions.
> >
> >Being able to have 'partial achitectures' which are actually different
> >baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that
> >has been discussed many times, but no-one has ever cared enough to
> >actually implement it.
> >
> >This is particularly relevant on mips, where inconsistent ISA changes
> >over the years mean that make picking one 'base ISA' is very
> >unsatisfactory, and they would like a way of having alternative ISA
> >(not ABI) builds of a significant set of packages (anthing where speed
> >actually matters, so libc, some core things and anything
> >codec-related, at least). (The rasbian port could have done things
> >this way and stayed within Debian for example, but it was easier to
> >derive).
> >
> >Some details of a proposal for implemnting this are covered in section
> >2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results
> >It would need fleshing out some more to actually be complete.
>
> (These ideas could also be applied for packages compiled with special
> characteristics, like optimised for multimedia instructions; or
> compiled with address sanitiser, undefined behaviour sanitiser, etc --
> somebody was talking about this in DebConf, I think that it was
> Bálint).
>
> Honest question, not a snarky one; but after reading your e-mail and the
> proposal it is still not very clear to me what's the fundamental
> underlying difference (or the advantage, in terms of which problems
> solves better, and how) between a partial architecture, a full
> architecture which possibly doesn't build a [large?] subset of packages
> (there are mechanisms like "not-for-us" and "package-arch-specific",
> which you probably know better than me), and an "overlay"-like
> repository such as experimental or security-updates (although I am aware
> that overlays don't get packages to build in the same way as arches, one
> has to target them).
Right, to some degree the same effects can be achieved in various
ways. And there are various pros/cons.
> If I understand correctly what I read from partial arches, there has to
> be a common baseline and baseline has to be the lowest common
> denominator, in the case of i386/i686 (or armel/armhf),
Some confusion here:
i386 is a Debian arch and thus an ABI. The
baseline ISA can be 486, 586, 686.
armel and armhf are _different_ ABIs (and thus debian architectures),
whose respective baseline ISAs are armv4t and armv7 respectively.
Nevertheless, I think you have understood the concept of each ABI
having a 'lowest common denominator' ISA. I'll just ignore the
confused use of 'armel' as an example of an ISA, not an ABI, below.
> the baseline has
> to be i386 or armel (so you can boot in the baseline, and then enable
> the "flavour"/partial-arch more suited to your hardware). And since in
> the example of Intel it is widely used and capable hardware, people
> could want almost every package. If armel cannot cope with some
> packages (e.g. 32-bit arches already having real trouble
> compiling/linking some packages), the packages would be put in some
> "not-for-us", or simply let to fail, as it probably happens already.
>
> In that case, the amount of compiled packages would be about the same,
> the storage about the same, etc. The only thing that we would reuse is
> a small set of packages that allow users to start the machine and enable
> the "flavour". I don't think that there would be much difference with
> having two full architectures?
Possibly. The main thing is that debian architectures define an ABI,
and lots of basic tools reply on this. Various things could break, or
at least not do what you expect if we had two arches called 'i386' and
'i686', which were the same ABI. e.g ask dpkg which 'architecture' you
are running on after installing 'i686' and it would return 'i386'.
This is why the proposal for a different mechanism based on HWCAPS and
a dpkg field to distinguish between different baselines/instructions
builds of an arch/ABI, exists.
And in practice (for x86/i386) you wouldn't need to convert
'nearly-all' packages to use i686-flavour, because for most of them
you almost certainly can't tell the difference between the 585 and 686
versions. On the other hand there probably are cases where it really
would make a huge difference and you'd want to rebuild 'nearly
everything' in 'newer flavour', so that case is worth thinking about.
> In the case that it works like an overlay-like repository
> ("jessie+i686", "jessie/i686" or whatever the convention), one could pin
> this repository to take precedence and so install packages from it.
Yes, I think that would work for installing things. (But you'd have to
have replacement gcc (and other compilers) packages to make sure the
correct 'use 686' defaults were used in anything you rebuild,
otherwise it'll revert to the jessie+586 baseline).
> It
> doesn't work very well if one thinks of unstable/experimental (packages
> not being available at the same time), but it does if you imagine using
> multiarch already today with stable releases -- you have all packages
> there on both arches at the same time.
No - both flavours would use the same multiarch-location - because
they are the same ABI (multiarch is about ABIs, not ISA
levels/optimisations)
> If the amount of packages available is again "almost all", it doesn't
> gain much over full ports in terms of CPU usage and storage.
> In all cases, I assume that humanpower needed to tend the ports is about
> the same.
>
>
> So, in summary, I don't see these mechanisms as very different in terms
> of resources compared to what I learn from partial architectures so far.
>
> The main difference that I see among them is that full ports and overlay
> repositories already work and don't need modification to existing
> tools/practices; multiarch with compatible ports in the same machine and
> overlay repositories and apt-pinning already work today.
Yes you can do all that stuff, but you need to bear in mind that the
rebuilt/optimised flavour is _not_ a different Debian arch so far as
dpkg is concerned, only a new repository. That may well be sufficient for
many purposes. (This is how Raspbian armhf is done (rebuild armhf with
armv6 ISA) and keep it in separate repository).
The fact that you can mostly get by with alternate repositories, and
building critical packages with foo-686 versions (libc, some codecs)
is probably why no-one has ever done the design and dpkg work for the
more general slution. IMHO it's all a bit of a bodge though, and the
right way to deal with this stuff in Debian is to annotate packages
with HWCAPS/ISA metadata.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Attachment:
signature.asc
Description: Digital signature