On Thu, 2014-06-05 at 17:31 +0800, Yunqiang Su wrote: > On Mon, Jun 2, 2014 at 7:57 PM, Ben Hutchings <b...@decadent.org.uk> wrote: [...] > >> diff -Nru linux-3.15~rc7/debian/config/mips64/defines > >> linux-3.15~rc7/debian/config/mips64/defines > >> --- linux-3.15~rc7/debian/config/mips64/defines 1970-01-01 > >> 00:00:00.000000000 +0000 > >> +++ linux-3.15~rc7/debian/config/mips64/defines 2014-05-29 > >> 00:26:03.000000000 +0000 > >> @@ -0,0 +1,50 @@ > >> +[base] > >> +flavours: > >> + r4k-ip22 > >> + r5k-ip32 > >> + sb1-bcm91250a > >> + 5kc-malta > >> + octeon > > > > I don't think we should build such a large number of flavours for a new > > architecture. Most of those machines are obsolete by now. > > Which one do you think to be kept? > sb1-bcm91250a and octeon ?
That seems sensible - those would cover all of Debian's own MIPS hardware that can run big-endian. [...] > >> diff -Nru linux-3.15~rc7/debian/config/mipsel/defines > >> linux-3.15~rc7/debian/config/mipsel/defines > >> --- linux-3.15~rc7/debian/config/mipsel/defines 2014-05-06 > >> 09:37:03.000000000 +0000 > >> +++ linux-3.15~rc7/debian/config/mipsel/defines 2014-05-29 > >> 00:27:04.000000000 +0000 > > > > This patch does a little more than the subject says! > > > >> @@ -6,6 +6,7 @@ > >> loongson-2e > >> loongson-2f > >> loongson-3 > >> + octeon > > > > Is it useful to run Octeon on little-endian mode? > > I have not very clear for mipsel while we have mips64el only now. > Maybe we should keep octeon in mips64el while not in mipsel OK. > > [...] > >> diff -Nru > >> linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules > >> linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules > >> --- linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules > >> 1970-01-01 00:00:00.000000000 +0000 > >> +++ linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules > >> 2014-05-29 02:20:50.000000000 +0000 > >> @@ -0,0 +1 @@ > >> +#include <btrfs-modules> > > [...] > > > > All the installer modules configuration files should be copied *by > > reference* from mips or mipsel, either using a relative #include or a > > directory symlink. > > > > OK, I will link them, while diff (debdiff) treats them as normal file. That's true, but if you check out the source using svn or git-svn you can make a diff that shows symlinks. git-svn would be best, as you could then split your changes up into multiple patches: 1. Move common MIPS kernel config files to kernelarch-mips 2. Add kernel config files for mips64/mips64el 3. Add installer config files to mips64/mips64el > the dsc file is here: > http://mips.wicp.net:9998/mips2/temp/ Looking at the new patch: > --- linux-3.15~rc8/debian/config/defines 2014-05-14 15:41:05.000000000 > +0000 > +++ linux-3.15~rc8/debian/config/defines 2014-06-05 06:23:54.000000000 > +0000 > @@ -14,6 +14,8 @@ > m68k > mips > mipsel > + mips64 > + mips64el > or1k > powerpc > powerpcspe > @@ -25,7 +27,7 @@ > sparc > sparc64 > x32 > -compiler: gcc-4.8 > +compiler: gcc-4.9 > featuresets: > none > rt This is the default setting for all architectures; you must not change it but instead override it in debian/config/mips64/defines and debian/config/mips64el/defines. [...] > diff -Nru linux-3.15~rc8/debian/config/mips/defines > linux-3.15~rc8/debian/config/mips/defines > --- linux-3.15~rc8/debian/config/mips/defines 2014-05-06 09:37:03.000000000 > +0000 > +++ linux-3.15~rc8/debian/config/mips/defines 2014-06-05 05:43:07.000000000 > +0000 > @@ -12,29 +12,47 @@ > image-file: vmlinux > > [image] > -initramfs: false > +initramfs: true > install-stem: vmlinux > > [r4k-ip22_description] I don't think you can simply change this, as some of the boot loaders used on old MIPS systems don't support an initramfs. If it was that simple, we would have done it already! [...] > --- linux-3.15~rc8/debian/installer/mips64el/package-list 1970-01-01 > 00:00:00.000000000 +0000 > +++ linux-3.15~rc8/debian/installer/mips64el/package-list 2014-06-05 > 05:59:58.000000000 +0000 > @@ -0,0 +1,11 @@ > +# This file is used to build up the control file. The kernel version and > +# "-di" are appended to the package names. Section can be left out. So can > +# architecture, which is derived from the files in the modules directory. > +# It overwrites specifications from /usr/share/kernel-wedge/package-list. > +# > +Package: kernel-image > +Provides_sb1-bcm91250a: ata-modules, ext2-modules, ext3-modules, > ext4-modules, rtc-modules > +Provides_5kc-malta: ata-modules, ext2-modules, ext3-modules, ext4-modules, > rtc-modules > +Provides_loongson-2e: ata-modules, ext2-modules, ext3-modules, ext4-modules, > rtc-modules > +Provides_loongson-2f: ata-modules, ext2-modules, ext3-modules, ext4-modules, > rtc-modules > +Provides_loongson-3: ata-modules, ext2-modules, ext3-modules, ext4-modules, > rtc-modules [...] As all the kernel flavours have the same things built-in, you can write a single 'Provides:' line instead. *But* the mips64/mips64el kernels will always boot with an initramfs, so the ATA drivers and ext4 can be built as modules. I think the configuration overrides that make them built-in on mips/mipsel should be kept there and not moved into the common configuration in kernelarch-mips. You could do that as a later cleanup patch, though. Ben. -- Ben Hutchings You can't have everything. Where would you put it?
signature.asc
Description: This is a digitally signed message part
