Re: [Stretch] Status for architecture qualification
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: maintainer communication
On Mon, Dec 23, 2013 at 10:59 PM, Finn Thain wrote:
>> >Why is CONFIG_SERIAL_PMACZILOG to be disabled? And why was
>>
>> See the discussion in the thread before this message.
>
> I've seen no discussion of this on debian-68k or linux-m68k. What
> discussion are you referring to?
>
> The subject of this thread (before you shortened it) was "maintainer
> communication (was Re: Debian kernel regression, was Re: Modernizing a
> Macintosh LC III)".
>
> That discussion covered both the usefulness of the serial console (i.e.
> CONFIG_SERIAL_PMACZILOG) and the problematic disappearance of
> CONFIG_EARLY_PRINTK.
I guess it's about the crash on non-Mac when passing debug=serial.
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
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMuHMdVDH9Jw979gU=+GVCdwXzDFww+tNFY=pmd4fkpmfaq...@mail.gmail.com
Re: Bits from the Release Team (Jessie freeze info)
On Wed, Oct 23, 2013 at 12:36 AM, Stewart Smith
wrote:
> Jenkins can have slaves on remote hosts, via SSH. It runs a small java
> app there, so as long as the arch has a JVM then you're pretty right.
For whatever definition of small. I've seen it consuming 1 GiB of memory...
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
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/camuhmdvz3jwmdujds762z-cnhv4z5c9wuuf5rkanarqbsdx...@mail.gmail.com
Re: [Linux-fbdev-devel] Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later
On Tue, 15 Feb 2005, Frans Pop wrote:
> These values also tell that the old default mode was 1152x900-66,
> resulting in a 144x56 textconsole. My personal opinion is that that is
> very high for a default mode. The 1024x768-70 (resulting in 128x48) I've
> been using now (or maybe even something a bit lower) seems more
> reasonable to me.
1152x900 is the default Sun mode.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sparc scsi esp depends on pci & hangs on boot
On Wed, 23 Jul 2003, David S. Miller wrote:
> On Wed, 23 Jul 2003 08:02:22 +0100
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jul 22, 2003 at 11:57:14PM -0700, David S. Miller wrote:
> > > I don't see why this is a problem. Either do this, or fix
> > > asm-generic/dma-mapping.h which is not GENERIC because it
> > > depends upon something SPECIFIC, specifically PCI.
> >
> > The latter is what need to be done.
>
> I'll do the following for now.
>
> # This is a BitKeeper generated patch for the following project:
> # Project Name: Linux kernel tree
> # This patch format is intended for GNU patch command version 2.5 or higher.
> # This patch includes the following deltas:
> #ChangeSet1.1518 -> 1.1519
> # include/asm-sparc64/dma-mapping.h 1.1 -> 1.2
> # include/asm-sparc/dma-mapping.h 1.1 -> 1.2
> #
> # The following is the BitKeeper ChangeSet Log
> #
> # 03/07/23[EMAIL PROTECTED] 1.1519
> # [SPARC]: Do not include asm-generic/dma-mapping.h if !CONFIG_PCI.
Yep, that's what I did for m68k as well (inspired by s390 which never has PCI
and thus an empty dma-mapping.h).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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: reiserfs empirical study (very long)
On Thu, 31 May 2001, Steven Hanley wrote:
> On Wed, May 30, 2001 at 05:39:09PM -0700, Mike Fedyk wrote:
> > On Wed, May 30, 2001 at 02:09:16PM -0700, Andrew Sharp wrote:
> > > Cameron Berkenpas wrote:
> > > >
> > > > I thought I read somewhere that XFS is working on PPC..
> > > > I take it that info was incorrect?
> > >
> > > I think what you read is that "...they are working on it for PPC."
> > > Supposedly an endian-fixed version should be available soonish.
> > >
> > I would believe that XFS wouldn't have any endian problems; since XFS was
> > origionally on a big-endian system (mips/irix) before.
>
> unfortunately not, they had to add a lot of code and change a fiar bit of
> stuff to get XFS to work inside linux, all this work and development was done
> on x86 boxen, as to how far they are towards having this working on linux/ppc
> now I dont know.
Hmm, I thought we had convinced them to keep on using big-endian for the
metadata at Linux Kongress in Augsburg.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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: reiserfs empirical study (very long)
On Wed, 30 May 2001, Andrew Sharp wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 30 May 2001, Andrew Sharp wrote:
> > > The big endian patches change the code to use little endian ordering
> > > for all on-disk structures. IMO this is a mistake, and certainly
> > > costs a dear performance penalty, because on big endian processors,
> > > this method requires converting endianness both ways (reading and
> > > writing) for all meta data. I submit that there is little reason
> > > for this, and the performance cost is not worth the very dubious
> > > feature of having the file system be moveable to little endian
> > > systems, like x86. Note that except in few cases, the disk labels
> >
> > We had the same discussion many years ago about ext2fs, and a few years
> > later
> > about XFS. In fact m68k and ppc used to have a big-endian ext2fs.
> >
> > Now ext2fs is defined to store metadata in little-endian order, and XFS to
> > store metadata in big-endian order. This was done for interoperability
> > reasons.
> >
> > Since people do want to exchange disks between machines, the alternative
> > was to
> > support both endiannesses. In fact m68k did have a bi-endian ext2fs for a
>
> I would actually like to hear more about these discussions. Are
> there any archives? Are they too old? Geez, if some silly person
M68k switched from big-endian to standard (little-endian) ext2fs in 1995.
PPC followed in late 1996.
Check out mailing list archives for Linux/m68k, Linux/PPC, and probably
linux-kernel as well.
> wants to take a disk from one machine to another, well, that is what
> vfat is for, no? ~:^)
If the system disk of my PPC box dies, I'll be happy to restore it from backup
on some other machine...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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: reiserfs empirical study (very long)
On Wed, 30 May 2001, Andrew Sharp wrote:
> The big endian patches change the code to use little endian ordering
> for all on-disk structures. IMO this is a mistake, and certainly
> costs a dear performance penalty, because on big endian processors,
> this method requires converting endianness both ways (reading and
> writing) for all meta data. I submit that there is little reason
> for this, and the performance cost is not worth the very dubious
> feature of having the file system be moveable to little endian
> systems, like x86. Note that except in few cases, the disk labels
We had the same discussion many years ago about ext2fs, and a few years later
about XFS. In fact m68k and ppc used to have a big-endian ext2fs.
Now ext2fs is defined to store metadata in little-endian order, and XFS to
store metadata in big-endian order. This was done for interoperability reasons.
Since people do want to exchange disks between machines, the alternative was to
support both endiannesses. In fact m68k did have a bi-endian ext2fs for a
while, which supported both little and big-endian ext2fs. However, this was
even more costly because all byteswapping decisions had to be made at runtime.
Compare this to the static case, where the compiler can optimize all
byteswapped accesses.
> alone would prevent this. I would very much like to see some endian
> patches that don't have this affect. I believe that the large file
> I/O performance and large directory tree copy performance would show
> a definite increase. It may be too late now.
Until you can prove there's a significant performance difference, I'm afraid
Reiserfs will stay little-endian...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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: Binutils no longer autobuilding the cross-compiling packages...
On Wed, 18 Apr 2001, Meelis Roos wrote:
> CCC> If there are any objections, please feel free to email me. I don't plan
> CCC> on keeping them buried forever...only until a better way is found to
> CCC> generate them in a policy-compliant manner and also in manner that
> CCC> won't impact slower/older architectures like m68k quite as much
>
> I find the -m68k variant useful (or, rather, convenient) and I do use it to
> cross-compile for m68k. But it's not too bad if they are gone - it's quite
> easy to build cross-binutils.
I think he was talking about building cross-compilers on the m68k platform, not
about cross-compilers to generate m68k binaries.
Yes, it's indeed useful to have a cross-compiler for a slow architecture on a
fast architecture. But not vice versa, I guess :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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
