On Thu, 2014-10-23 at 01:22 +0200, Ralf Baechle wrote: > On Wed, Oct 22, 2014 at 11:15:40PM +0100, Ben Hutchings wrote: > > > > > > > That's probably more of an implementation detail. I'm more concerned about > > > the overall bloat. I think many embedded users are so addivted to benchmark > > > results that this going to make or break the whole scheme. > > > > If you can make relocation a configuration option (as on x86), it would > > allow distributions to build multiplatform kernels without preventing > > embedded users from building a kernel optimised for their specific > > system. But I know very little about MIPS or how intrusive the changes > > for relocation would have to be. Perhaps it would be too much of a > > maintenance burden to make this an option. > > The scope of the changes is relativly limited - we're much more concerned > about the impact on binary size, memory size or performance of the > various approaches under discussion. > > I wonder kernels for which platforms would Debian want to unify? I don't have high expectations for being able to unify those we currently support. Realistically, I expect that most development effort will go into new platforms. (What we saw with ARM was that multi-platform was implemented for most ARMv7 platforms (for which we now need only 2 configurations) but only slowly for older chips (4 configurations, and that's after dropping 2 platforms).) Anyway, we have one 32-bit configuration for each byte order (4kc-malta), and the following 64-bit configurations: [big-endian] r4k-ip22: CONFIG_SGI_IP22, CONFIG_CPU_R4X00 r5k-ip32: CONFIG_SGI_IP32, CONFIG_CPU_R5000 sb1-bcm91250a: CONFIG_SIBYTE_SWARM, CONFIG_CPU_SB1 5kc-malta: CONFIG_MIPS_MALTA, CONFIG_CPU_MIPS64_R1 octeon: CONFIG_CAVIUM_OCTEON_SOC [little-endian] sb1-bcm91250a: CONFIG_SIBYTE_SWARM, CONFIG_CPU_SB1 5kc-malta: CONFIG_MIPS_MALTA, CONFIG_CPU_MIPS64_R1 loongson-2e: CONFIG_MACH_LOONGSON, CONFIG_LEMOTE_FULOONG2E loongson-2f: CONFIG_MACH_LOONGSON, CONFIG_LEMOTE_MACH2F loongson-3: CONFIG_MACH_LOONGSON, CONFIG_LOONGSON_MACH3X In general, I want our kernel packages to support any hardware that is or has been generally available to buy, that can feasibly run a general purpose distribution. I'm somewhat hopeful that Prpl members will be introducing new platforms that fit this description in the near future. But I also want the packages to build natively in a few hours on each architecture. Currently, it takes about 17 hours on little-endian (Loongson 3A, quad-core) and longer on big-endian (Octeon v0.3, 6 cores used). So I can't accept a further increase in the number of configurations as new MIPS platforms appear. Without multi-platform support, we will have to drop one platform for each one we add, so we'll have to be quite picky about adding them. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less.
Attachment:
signature.asc
Description: This is a digitally signed message part