Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Preparation for creating netbsd-7 branch
christos@ wrote:
> On Jul 20, 3:50am, tsutsui%ceres.dti.ne.jp@localhost (Izumi Tsutsui) wrote:
> -- Subject: Re: Preparation for creating netbsd-7 branch
>
> | christos@ wrote:
> |
> | > In article <140719232527.M0121767%mirage.ceres.dti.ne.jp@localhost>,
> | > Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
> | > >> On behalf of the release engineering team, I am happy to announce that
> | > >> the release process for NetBSD 7.0 is now underway.
> | > >
> | > >Does anyone (core? releng?) has a particular plan about
> | > >the default MACHINE_ARCH for each arm ports?
> | >
> | > Let's discuss it. What do you propose?
> |
> | I asked matt@ on port-arm last year and got no answer.
> | http://mail-index.netbsd.org/port-arm/2013/10/26/msg002073.html
> | I think (other) Core members should handle it.
>
> Yes, I've been trying to follow that thread. Can you please summarize
> the problem and propose a solution? Is it a backwards compatibility issue?
> Or do we need to worry about binaries produced with sf on hf able machines
> in the future? Why would one do that? To be compatible with old machines?
The main problem is lack of design description with random changes.
http://mail-index.netbsd.org/port-arm/2013/10/26/msg002069.html
http://mail-index.netbsd.org/port-arm/2013/10/27/msg002075.html
Without specification, no idea what is intentional and what is broken.
Anyway, most concerns are too late to discuss.
- MACHINE_ARCH should be static or dynamic
- how sysctl hw.machine_arch should be handled
- different MACHINE_ARCH for kernel and userland should be allowed or not
- different MACHINE_ARCH should be used for armv4/v6/v7 or not
- a single kernel should handle different MACHINE_ARCH userland or not
- should we use different MACHINE_ARCH for softfloat and hardfloat or not
All of these usages have been changed from other MACHINE_ARCH.
For the next release, core/releng should decide per current implementation:
- how the default userland MACHINE_ARCH should be deteremined
- how to handle migration from old ABI to new one on sysinst
- which MACHINE_ARCH binaries should be prepared for official packages
etc. for the new MACHINE_ARCH strategies.
---
Izumi Tsutsui
Home |
Main Index |
Thread Index |
Old Index