This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Stepping down


On 06/10/2015 09:58 PM, Rich Felker wrote:
> On Wed, Jun 10, 2015 at 05:10:25PM -0700, Roland McGrath wrote:
>> Thanks for all your contributions over the years, Kaz.  IMHO you have
>> been an excellent machine maintainer for Linux/SH.  You've most
>> certainly been an excellent contributor to libc in other ways, and for
>> far longer than most people.
>>
>> Do you know of anyone else who might step forward to maintain the SH
>> port?  Are there Linux distributions that build for SH?
>>
>> If it has no maintainer but continues to build fine in some distro,
>> then that's fine.  But if either it becomes broken and nobody is
>> signed on to fix it, or we have no reason to think anyone has actually
>> built it lately, then we'll want to remove it from the tree.
> 
> Did you see this?
> 
> http://lwn.net/SubscriberLink/647636/fdb277e9550d7141/
> 
> So far their work is focused on sh2/nommu,

Largely because the remaining sh4 patents don't expire until next year,
so we can't clone the newer chip yet.

We're also focusing on smp support before tackling adding an mmu (which
is funky because nommu SMP is a concept Linux doesn't quite have
infrastructure for yet). Then after sh4 mmu support comes 64 bit
support, so we should be busy for a while.

But _really_ what we're focused on right now is getting the VHDL cleaned
up enough to push to a public git repo (under a BSD license),
documenting the bitstream build and install (and installing the pile of
prerequisite packages you need to get a working bitstream toolchain),
moving our internal development discussions to public mailing lists,
maybe a wiki... The deadline for the linuxcon talk and having stuff
ready to ship didn't quite line up as cleanly as we'd hoped. :)

My current todo list is for the above project is:

1) sh2-elf toolchain for bootloader (aboriginal)
2) sh2-linux toolchain for kernel and userspace (aboriginal)
3) kernel patches (board support for 4.0 including 0pf_defconfig)
4) initramfs (aboriginal linux with hush instead of ash+toybox fixes)
5) bitstream compiler install instructions (xilinx ice thing)
6) jtag install instructions (digilent, or numato python tool)
7) vhdl source files cleanup and post
8) vhdl build files with prerequisite package list (cloture, etc).
9) Mailing lists and documentation and support and...

I'm mostly done with #1 and #2, partway through 3-6, have #7 in my inbox
from another engineer...

> which glibc probably
> doesn't support, but keeping/restoring superh as a
> maintained/supported platform at the kernel and toolchain levels is
> important and they might have ideas for someone to take on the glibc
> port maintainership.

We're very interested in superh, but I'm not sure how interested we are
in glibc? (I can't personally do it, I'm swamped.)

I'm doing the BSP for the j2 project, which means when I'm not
head-scratching at kernel patches I'm trying to move all the
software-side stuff to current package versions. But on the libc side
we're in the process of transitioning from uclibc (which is moribund) to
musl-libc (earlier this month we sent the maintainer test hardware and
arranged a skype call with him to provide background info on the
architecture). I was vaguely thinking of taking a stab at getting bionic
to run at some nebulous point in the future because android ships a
billion units annually so that's a thing. (Of course we hope to ship a
billion sensor units with musl, but probably not this year.)

If glibc has nommu support for any target, I'm unaware of it. Even with
an mmu, I've maintained a sh4 target in my Aboriginal Linux project
since 2008 but never built glibc for that target. (I started with uclibc
and am switching to musl in my Copious Free Time.) It's _nice_ for glibc
to support this, but not in our critical path for anything.

I note that qemu has excellent sh4 support (it's how I developed and ran
aboriginal's sh4 target), so if all you want is basic regression testing
that's probably pretty reasonable. There seems to be some basic sh4
support in debian (https://wiki.debian.org/SH4) so maybe a native build
image of that could run? (The qemu r2d board emulation is hardwired to
64 megs ram but I've thrown swap files at it to build stuff natively,
and presumably qemu and the kernel could be patched to add more physical
memory to the emulation...)

If a prospective new maintainer would like an sh2 board I can probably
mail them one with instructions on how to use it, but again: nommu and
it's not growing one for at least a year.

> Rich

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]