On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux <syslinux at zytor.com> wrote:> From: Sylvain Gault <sylvain.gault at gmail.com> > > Some linker scripts were splitted into i386 and x86_64 versions in > commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were > left there. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> > --- > core/syslinux.ld | 414 ------------------------------------------------ > core/x86_64/syslinux.ld | 389 --------------------------------------------- > efi/syslinux.ld | 176 -------------------- > mbr/mbr.ld | 73 --------- > memdisk/memdisk.ld | 140 ---------------- > 5 files changed, 1192 deletions(-) > delete mode 100644 core/syslinux.ld > delete mode 100644 core/x86_64/syslinux.ld > delete mode 100644 efi/syslinux.ld > delete mode 100644 mbr/mbr.ld > delete mode 100644 memdisk/memdisk.ldRemoving mbr/mbr.ld makes 0 sense. MBRs are a BIOSism that won't be present on UEFI IA32 (aka i386) and X64 (aka x86-64 IA32-64 EM64T AMD64). I feel it makes more sense to remove the architecture-specific scripts. A MEMDISK-like system for UEFI would probably need to be implemented as a UEFI driver. As a result, it's questionable if it'd be a new variant of MEMDISK, built with some different code that's UEFI-specific or a completely different sub-project. efi/syslinux.ld and core/x86_64/syslinux.ld are no-brainers. core/syslinux.ld and core/i386/syslinux.ld get messy. For a cleaner look at how it appears it's been mismerged, consider "gitk c6bebc44.. -- core/{,i386/,x86_64/}syslinux.ld" then start at 8e5e9b0a and 6fa86596. 51529126 08ece8fc b7549a33 3b772bb6 275a269d affected core/syslinux.ld while it appears nothing really affected core/i386/syslinux.ld. -- -Gene
2015-10-15 12:53 UTC+02:00, Gene Cumm <gene.cumm at gmail.com>:> On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux > <syslinux at zytor.com> wrote: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> Some linker scripts were splitted into i386 and x86_64 versions in >> commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were >> left there. >> >> Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> >> --- >> core/syslinux.ld | 414 >> ------------------------------------------------ >> core/x86_64/syslinux.ld | 389 >> --------------------------------------------- >> efi/syslinux.ld | 176 -------------------- >> mbr/mbr.ld | 73 --------- >> memdisk/memdisk.ld | 140 ---------------- >> 5 files changed, 1192 deletions(-) >> delete mode 100644 core/syslinux.ld >> delete mode 100644 core/x86_64/syslinux.ld >> delete mode 100644 efi/syslinux.ld >> delete mode 100644 mbr/mbr.ld >> delete mode 100644 memdisk/memdisk.ld > > Removing mbr/mbr.ld makes 0 sense. MBRs are a BIOSism that won't be > present on UEFI IA32 (aka i386) and X64 (aka x86-64 IA32-64 EM64T > AMD64). I feel it makes more sense to remove the > architecture-specific scripts.As the commit line say, it removes unused linker scripts. This commit intended to be really dumb: unused = delete. And mbr/mbr.ld isn't used. I think it's detter delete this one and then move mbr/i386/mbr.ld to mbr/mbr.ld in a second commit. Which I didn't do because I wasn't sure of that. I didn't delete mbr/x86_64/mbr.ld because I wasn't sure it wouldn't be used. It will be removed in the next version of this patch series (see below).> > A MEMDISK-like system for UEFI would probably need to be implemented > as a UEFI driver. As a result, it's questionable if it'd be a new > variant of MEMDISK, built with some different code that's > UEFI-specific or a completely different sub-project.In doubt, I think the arch-specific scripts could be left there, waiting for a working implementation of memdisk for UEFI.> > efi/syslinux.ld and core/x86_64/syslinux.ld are no-brainers. > > core/syslinux.ld and core/i386/syslinux.ld get messy. For a cleaner > look at how it appears it's been mismerged, consider "gitk c6bebc44.. > -- core/{,i386/,x86_64/}syslinux.ld" then start at 8e5e9b0a and > 6fa86596. 51529126 08ece8fc b7549a33 3b772bb6 275a269d affected > core/syslinux.ld while it appears nothing really affected > core/i386/syslinux.ld.I also noted the commit 9057b5337c44c08343d403da2a31636dfc1ad741 in my list of lost changes. Yeah, I'm preparing a port of all the commits that affected core/syslinux.ld that were not in core/i386/syslinux.ld. If you want to take a look at it, a WIP version of this is on my github branch wip/cleanup-linkerscripts. https://github.com/Celelibi/syslinux/tree/wip/cleanup-linkerscripts (Still need a bit of work and testing.) Celelibi
> As the commit line say, it removes unused linker scripts. This commit > intended to be really dumb: unused = delete. And mbr/mbr.ld isn't > used. I think it's detter delete this one and then move > mbr/i386/mbr.ld to mbr/mbr.ld in a second commit. Which I didn't do > because I wasn't sure of that. > > I didn't delete mbr/x86_64/mbr.ld because I wasn't sure it wouldn't be > used. It will be removed in the next version of this patch series (see > below).*morning english is broken english* I'll rephrase this: As the commit line say, it removes unused linker scripts. This commit intended to be really dumb: unused = delete. And since I wasn't sure mbr/x86_64/mbr.ld was actually used, I left it. I'll remove it and move mbr/i386/mbr.ld to mbr/mbr.ld in a second version of this patch series. Anyway, I think it's better to separate the dumb commit that remove the unused scripts from the more "risky" ones that may actually have an effect. Should it be to simplify bisection. If I may, I'd make a parallel with whitespaces commits. There are two ways of thinking: - either you only fix the whitespaces around the lines you actually change ; - or you fix the whitespaces of a whole file and make the changes a separate commit. Since I had several other files to delete, I choosed the latter way.