mips* port plans for the squeeze cycle

View: New views
7 Messages — Rating Filter:   Alert me  

mips* port plans for the squeeze cycle

by Marc Brockschmidt-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Heya,

As announced on dda [RT1], we want to get an impression when releasing
Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
2009, and some developers have noted that their planned changes wouldn't be
possible in this time frame. So, to find out when releasing would work for
most people, it would be great if you could answer the following questions:

Do you have any big changes planned? How much time would they take, and
what consequences are there for the rest of the project?

How many "big" transitions will the upcoming changes cause? When should those
happen? Can we do something to make them easier?

Thanks,
Marc

[RT1] http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html


attachment0 (202 bytes) Download Attachment

Re: mips* port plans for the squeeze cycle

by Martin Michlmayr :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

* Marc Brockschmidt <marc@...> [2009-08-16 14:40]:
> Do you have any big changes planned? How much time would they take, and
> what consequences are there for the rest of the project?
>
> How many "big" transitions will the upcoming changes cause? When should those
> happen? Can we do something to make them easier?

Do we have anything to say here?  I don't think there are any major
plans with regards to MIPS, are there?
--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-mips-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: mips* port plans for the squeeze cycle

by Florian Lohoff :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, Aug 18, 2009 at 08:20:02AM -1000, Martin Michlmayr wrote:

> Subject: Re: mips* port plans for the squeeze cycle
>
> * Marc Brockschmidt <marc@...> [2009-08-16 14:40]:
> > Do you have any big changes planned? How much time would they take, and
> > what consequences are there for the rest of the project?
> >
> > How many "big" transitions will the upcoming changes cause? When should those
> > happen? Can we do something to make them easier?
>
> Do we have anything to say here?  I don't think there are any major
> plans with regards to MIPS, are there?
I dont see any - ABI (n32 instead o32) changes are not there yet ...

Flo
--
Florian Lohoff                                         flo@...
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin


signature.asc (196 bytes) Download Attachment

Re: mips* port plans for the squeeze cycle

by Aurelien Jarno :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, Aug 18, 2009 at 08:20:02AM -1000, Martin Michlmayr wrote:
> * Marc Brockschmidt <marc@...> [2009-08-16 14:40]:
> > Do you have any big changes planned? How much time would they take, and
> > what consequences are there for the rest of the project?
> >
> > How many "big" transitions will the upcoming changes cause? When should those
> > happen? Can we do something to make them easier?
>
> Do we have anything to say here?  I don't think there are any major
> plans with regards to MIPS, are there?

* Switch the default ABI to mips2 instead of the current mips1 ABI. The
  mips1 ABI corresponds to R3000 CPUs that we don't support anymore for
  a lot of time. This lead us to writing ugly patches using ".set mips
  2" when using ll/sc instructions for atomic code in some packages.

This should only be only change in GCC that I plan to do unless someone
else volunteer.


* binutils currently has bugs and generate broken -fPIE binaries.
  While this is currently workarounded in a lot of package by not using
  -fPIE on mips(el), it is something that should be solved for the
  release.

  I have already started working on that, but help is welcome.


* Kernel and d-i support for these new mips-based laptop.


--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-mips-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: mips* port plans for the squeeze cycle

by Matthias Klose :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 16.08.2009 14:40, Marc Brockschmidt wrote:

> Heya,
>
> As announced on dda [RT1], we want to get an impression when releasing
> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
> 2009, and some developers have noted that their planned changes wouldn't be
> possible in this time frame. So, to find out when releasing would work for
> most people, it would be great if you could answer the following questions:
>
> Do you have any big changes planned? How much time would they take, and
> what consequences are there for the rest of the project?
>
> How many "big" transitions will the upcoming changes cause? When should those
> happen? Can we do something to make them easier?

binutils for mips currently shows some regressions (#519006) and non-working PIE
support (#532821). The regression is addressed upstream, the non-working PIE
support needs a test case and forwarding upstream.

   Matthias


--
To UNSUBSCRIBE, email to debian-mips-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: mips* port plans for the squeeze cycle

by Florian Lohoff :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, Aug 19, 2009 at 02:25:13PM +0200, Aurelien Jarno wrote:

> > Do we have anything to say here?  I don't think there are any major
> > plans with regards to MIPS, are there?
>
> * Switch the default ABI to mips2 instead of the current mips1 ABI. The
>   mips1 ABI corresponds to R3000 CPUs that we don't support anymore for
>   a lot of time. This lead us to writing ugly patches using ".set mips
>   2" when using ll/sc instructions for atomic code in some packages.
>
> This should only be only change in GCC that I plan to do unless someone
> else volunteer.
You mean switching to N32 instead O32? There is no point in switching to mips2
just for dropping the little patches. If we start changing something we should
drop mips1 aka r3k/32bit support (And early R4k with 64bit bugs) and switch to
n32 using a more efficient ABI.

Flo
--
Florian Lohoff                                         flo@...
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin


signature.asc (196 bytes) Download Attachment

Re: mips* port plans for the squeeze cycle

by Aurelien Jarno :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, Aug 20, 2009 at 11:27:31PM +0200, Florian Lohoff wrote:

> On Wed, Aug 19, 2009 at 02:25:13PM +0200, Aurelien Jarno wrote:
> > > Do we have anything to say here?  I don't think there are any major
> > > plans with regards to MIPS, are there?
> >
> > * Switch the default ABI to mips2 instead of the current mips1 ABI. The
> >   mips1 ABI corresponds to R3000 CPUs that we don't support anymore for
> >   a lot of time. This lead us to writing ugly patches using ".set mips
> >   2" when using ll/sc instructions for atomic code in some packages.
> >
> > This should only be only change in GCC that I plan to do unless someone
> > else volunteer.
>
> You mean switching to N32 instead O32? There is no point in switching to mips2
> just for dropping the little patches. If we start changing something we should
> drop mips1 aka r3k/32bit support (And early R4k with 64bit bugs) and switch to
> n32 using a more efficient ABI.

No, staying with o32, but "dropping" mips1 support from the toolchain and
switching to mips2 by default. That's the ABI we are using in practice,
as we have a lot of ".set mips2" in our archive. That's just changing
GCC, nothing more.

The goal with those small patch is actually not to be able to drop
them, but to stop writing new ones and having people complaining about
MIPS because of that.

Switching to N32 is something really interesting, but that requires
creating a new port. Moreover it does not run on MIPS32 CPU, so we
may have to keep the two ports in parallel.

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-mips-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...