mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Bryan Hundven <bryanhundven@gmail.com>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Future plans for uClibc-ng?
Date: Sun, 3 Jan 2016 01:35:26 -0800	[thread overview]
Message-ID: <20160103093526.GB25330@hp2000d> (raw)
In-Reply-To: <20160103092726.GW30206@pengutronix.de>


[-- Attachment #1.1: Type: text/plain, Size: 1746 bytes --]

Robert,

On Sun, Jan 03, 2016 at 10:27:26AM +0100, Robert Schwebel wrote:
> On Sat, Jan 02, 2016 at 06:02:37PM -0800, Bryan Hundven wrote:
> > > > I'm curious to know if ptxdist/OSELAS.Toolchain plans to support
> > > > uClibc-ng in the future?
> > > > 
> > > > http://www.uclibc-ng.org/
> > > 
> > > with half a year without commit to uClib git I'm considering it a dead
> > > project (I failed to verify mailing list activity as neither Firefox
> > > nor IE (!) allowed me to enter archives). uClibc-ng should be relatively
> > > easy to support as config system remained the same... Just tried and
> > > succeded. But are there any active uClibc users?
> > 
> > Well, I use it for a few platforms. And I get a lot of requests for it's
> > support on crosstool-ng.
> 
> We also use uclibc, especially for uCLinux systems. A few years ago, we
> mainlined Cortex-M3 support. It never gained business traction so far,
> because the BoM for a system is more expensive and less powerful than
> the cheaper systems with mmu (like Atmel 9x25, TI AM335, FSL MX23 etc).
> We still maintain EFM32 in the kernel.

Specifically, I still mess around with the EFM32 port, which is why this
was an interest. Although I realize it is not a focus of pengutronix.

But being able to turn on and off parts of uClibc/uClibc-ng also helps to
shrink the user-space footprint on other systems as well.

> However, these days we are seeing more and more Cortex-A cpus emerging
> with Cortex-M coprocessors. With these devices, running Linux on both
> cores is a real option (as far as I know, this is already implemented
> for Vybrid).
> 
> So uClibc stays relevant and will continue to be in OSELAS.Toolchain.

Indeed.

-Bryan

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2016-01-03  9:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-31 20:48 Bryan Hundven
2016-01-02 21:49 ` Ladislav Michl
2016-01-03  2:02   ` Bryan Hundven
2016-01-03  9:27     ` Robert Schwebel
2016-01-03  9:35       ` Bryan Hundven [this message]
2016-01-03  9:27   ` Alexander Dahl
2016-01-03 11:10     ` Ladislav Michl
2016-01-04 14:08       ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160103093526.GB25330@hp2000d \
    --to=bryanhundven@gmail.com \
    --cc=ptxdist@pengutronix.de \
    --cc=r.schwebel@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox