Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Mon, Jun 20, 2016 at 10:35:20PM +0200, Geert Uytterhoeven wrote:
> Yeah, apparently it's cheaper to bootstrap a complete new little endian
> platform than to fix portability issues in existing software...

I believe a big reason is that Nvidia cards expect little endian data,
and the overhead of converting between the host and the nvidia cards is
big enough to matter.

power8+ and power9 will have nvlink connections on the CPU for a reason
after all.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Geert Uytterhoeven]

On Mon, Jun 20, 2016 at 8:32 PM, Nelson H. F. Beebe  wrote:
> Recent traffic on this list has discussed Debian on PowerPC and
> big-endian vs little-endian.
>
> The next-generation US national laboratory facilities are to be based
> on PowerPC, and one source that I read mentioned little-endian, likely
> for binary file compatibility with files produced on Intel x86 and
> x86-64 CPUs: see

Yeah, apparently it's cheaper to bootstrap a complete new little endian
platform than to fix portability issues in existing software...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [Stretch] Status for architecture qualification

[Nelson H. F. Beebe]

Recent traffic on this list has discussed Debian on PowerPC and
big-endian vs little-endian.

The next-generation US national laboratory facilities are to be based
on PowerPC, and one source that I read mentioned little-endian, likely
for binary file compatibility with files produced on Intel x86 and
x86-64 CPUs: see

CORAL/Sierra
https://asc.llnl.gov/coral-info

The size, and budget, for such facilities suggests that there may be
financial support for Linux operating-system work on them.


---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

Re: [Stretch] Status for architecture qualification

[alexmcwhirter]

On 2016-06-20 10:29, John Paul Adrian Glaubitz wrote:

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz 
wrote:

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?


Well it is getting there.


The archive rebuild is done and around 11200 packages are up-to-date. 
It's
just the installer that needs work and someone needs to convince the 
release

team that ppc64 is something we want as a release architecture.

Adrian


Just out of curiosity, what's the stipulation with ppc64? Access to 
hardware shouldn't be a problem if ppc64el is a release arch. Maybe i'm 
just weird, but i would pick ppc64 over ppc64el any day. Other than my 
personal affinity for big endian cpu's, ppc64el only has support for one 
generation of cpu's whereas ppc64 should be able to run on everything 
from power4 / ppc970 and up without too much trouble.

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
> Well, we just did a full archive rebuild of "ppc64" to be able to
> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Well it is getting there.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/20/2016 04:05 PM, Lennart Sorensen wrote:
> Also I suspect many users of 64 bit capable freescale chips
> (e5500 and e6500 cores) are running 32 bit powerpc since they
> don't have enough ram to actually really gain anything
> from going to 64 bit, and the ppc64 port isn't done yet.

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Sun, Jun 19, 2016 at 08:35:02PM +0200, Florian Weimer wrote:
> Do they implement the ISA required by the existing Debian port?

Yes.

The only ones that don't are the Freescale 85xx and P10[12]x chips,
which are powerpcspe due to using the e500 core.

All the 83xx and 82xx chips which are still shipping in many current
products are plain old 32bit powerpc.  Also I suspect many users of 64
bit capable freescale chips (e5500 and e6500 cores) are running 32 bit
powerpc since they don't have enough ram to actually really gain anything
from going to 64 bit, and the ppc64 port isn't done yet.  But those
would be a case of running 32 bit on 64 bit.

-- 
Len Sorensen

Bug#827733: BusyBox Init + OpenRC

[Jon Boden]

Package: busybox
Version: 1.22.0-19
Tags: patch

Hi

With the package added by this patch (busybox-openrc), BusyBox Init can be used 
as PID 1 as a launcher for OpenRC (instead of SysV /sbin/init). This has the 
potential for faster boot times (but I haven't measured it, see 
https://blog.flameeyes.eu/2012/03/using-busybox-with-openrc).

I've only tested it on ubuntuBSD, but I think it should work fine on Debian 
too. I've also added Linux and Hurd versions of inittab.

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
diff -Nur -x changelog ../debian/busybox-openrc.links debian/busybox-openrc.links
--- ../debian/busybox-openrc.links	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-openrc.links	2016-06-20 13:47:35.911041000 +0200
@@ -0,0 +1,4 @@
+bin/busybox sbin/init
+bin/busybox sbin/halt
+bin/busybox sbin/reboot
+bin/busybox sbin/poweroff
diff -Nur -x changelog ../debian/control debian/control
--- ../debian/control	2015-08-07 23:39:01.0 +0200
+++ debian/control	2016-06-20 14:08:19.252858000 +0200
@@ -76,6 +76,23 @@
  busybox-initramfs provides a simple stand alone shell that provides
  only the basic utilities needed for the initramfs.
 
+Package: busybox-openrc
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, busybox, openrc
+Conflicts: sysvinit (<< 2.88dsf-44), sysvinit-core, upstart [linux-any], systemd-sysv [linux-any]
+Section: admin
+Description: BusyBox init for OpenRC
+ BusyBox combines tiny versions of many common UNIX utilities into a single
+ small executable. It provides minimalist replacements for the most common
+ utilities you would usually find on your desktop system (i.e., ls, cp, mv,
+ mount, tar, etc.). The utilities in BusyBox generally have fewer options than
+ their full-featured GNU cousins; however, the options that are included
+ provide the expected functionality and behave very much like their GNU
+ counterparts.
+ .
+ busybox-openrc provides a minimalist implementation of /sbin/init, configured
+ for use with OpenRC.
+
 Package: busybox-udeb
 Package-Type: udeb
 Architecture: any
diff -Nur -x changelog ../debian/inittab.hurd debian/inittab.hurd
--- ../debian/inittab.hurd	1970-01-01 01:00:00.0 +0100
+++ debian/inittab.hurd	2016-06-20 14:12:59.364964000 +0200
@@ -0,0 +1,28 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 tty1
+::respawn:/sbin/getty 38400 tty2
+::respawn:/sbin/getty 38400 tty3
+::respawn:/sbin/getty 38400 tty4
+::respawn:/sbin/getty 38400 tty5
+::respawn:/sbin/getty 38400 tty6
+::respawn:/sbin/getty 38400 console
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L ttyS0 9600 vt100
+#::respawn:/sbin/getty -L ttyS1 9600 vt100
+
+# Example how to put a getty on a modem line.
+#
+#::respawn:/sbin/mgetty -x0 -s 57600 ttyS3
diff -Nur -x changelog ../debian/inittab.kfreebsd debian/inittab.kfreebsd
--- ../debian/inittab.kfreebsd	1970-01-01 01:00:00.0 +0100
+++ debian/inittab.kfreebsd	2016-06-20 14:13:02.382742000 +0200
@@ -0,0 +1,27 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 ttyv0 xterm
+::respawn:/sbin/getty 38400 ttyv1 xterm
+::respawn:/sbin/getty 38400 ttyv2 xterm
+::respawn:/sbin/getty 38400 ttyv3 xterm
+::respawn:/sbin/getty 38400 ttyv4 xterm
+::respawn:/sbin/getty 38400 ttyv5 xterm
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L cuau0 9600 vt100
+#::respawn:/sbin/getty -L cuau1 9600 vt100
+
+# Example how to put a getty on a modem line.
+#
+#::respawn:/sbin/mgetty -x0 -s 57600 ttyd3
diff -Nur -x changelog ../debian/inittab.linux debian/inittab.linux
--- ../debian/inittab.linux	1970-01-01 01:00:00.0 +0100
+++ debian/inittab.linux	2016-06-20 14:13:05.623434000 +0200
@@ -0,0 +1,27 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 tty1
+::respawn:/sbin/getty 38400 tty2
+::respawn:/sbin/getty 38400 tty3
+::respawn:/sbin/getty 38400 tty4
+::respawn:/sbin/getty 38400 tty5
+::respawn:/sbin/getty 38400 tty6
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L ttyS0 

Bug#827718: init: open /dev/console on GNU/kFreeBSD

[Jon Boden]

Package: busybox
Version: 1.22.0-19
Tags: patch

FreeBSD kernel doesn't tell PID 1 the pathname of /dev/console through CONSOLE 
environment variable like Linux does. Instead it expects PID 1 to always open 
/dev/console.

This patch is tested on ubuntuBSD but I think it should work on Debian too (I 
haven't tested the whole init yet, but I verified that with my patch it can 
print to stdout).

I've also sent it to BusyBox bugzilla: 
https://bugs.busybox.net/show_bug.cgi?id=9031

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
Index: busybox-1.22.0/init/init.c
===
--- busybox-1.22.0.orig/init/init.c
+++ busybox-1.22.0/init/init.c
@@ -277,11 +277,19 @@ static void console_init(void)
 #ifdef VT_OPENQRY
 	int vtno;
 #endif
-	char *s;
 
+#if defined(__linux__)
+	char *s;
 	s = getenv("CONSOLE");
 	if (!s)
 		s = getenv("console");
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+	const char *s;
+	s = "/dev/console";
+#else
+#error "we don't know how to open the console on this system"
+#endif
+
 	if (s) {
 		int fd = open(s, O_RDWR | O_NONBLOCK | O_NOCTTY);
 		if (fd >= 0) {