[syslinux] [PATCH] Fix recognition of keeppxe option

Gene Cumm gene.cumm at gmail.com
Thu Jun 16 04:12:44 PDT 2016


On Wed, Jun 15, 2016 at 1:02 PM, Ady via Syslinux <syslinux at zytor.com> wrote:
>
>> On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote:
>> >
>> >> > kernel.c:new_linux_kernel() to load_linux.c:bios_boot_linux() because
>> >> > there is no convenient way in new_linux_kernel() to control the boot
>> >> > flags value.
>> >>
>> >> This is the part that has me questioning things and trying to recall
>> >> if any other KERNEL-like directives ever utilize keeppxe.
>> >>
>> >
>> > @Gene,
>> >
>> > Not being a developer myself, I don't understand this "other
>> > KERNEL-like directives" sentence. I do know what "kernel-like
>>
>> Those directives which acts like KERNEL, specifying a binary to
>> execute.  BOOT BSS COM32 COMBOOT CONFIG FDIMAGE LINUX LOCALBOOT PXE.
>>
>> > directives" means, but I do not know which one is the one you are
>> > referring to here, and why "_other_ KERNEL-like directives" would be a
>>
>> I'm referring to all of the above collectively.
>>
>> > concern. I mean, other than the behavior regarding file name
>> > extensions, shouldn't the KERNEL-like directives relevant in this case
>> > be equivalent to each other? (FWIW, I say "relevant" because I am
>> > assuming that the "CONFIG" and the "LOCALBOOT" directives are not so
>> > relevant in this context; are they?).
>>
>> KERNEL guesses what the proper loading method is and should generally
>> be avoided.  A few years back, a distribution had a kernel that ended
>> in ".0" while using KERNEL resulting in PXE behavior instead of LINUX.
>>
>
> Perhaps I wasn't clear in my question.
>
> As I said, I _do_ know what "KERNEL-like directives" means, which ones
> they are, and their behavior regarding file name extensions.
>
> The part that I did _not_ understand is (other than not being able to
> understand the code itself, since I am not a dev.):
>
> "...if any other KERNEL-like directives ever utilize keeppxe."
>
> When you wrote "any other..." I took it as "there is (at least) _one_
> kernel-like directive that is related or used or mentioned in the code
> you were referring to, and then there are _other_ kernel-like
> directives that were not explicitly related / used / mentioned in the
> code, and that you were not sure whether any (one) of these _other_
> kernel-like directives ever use / parse keeppxe (too).

Just glancing at file names and function names, I believe this patch
makes it ONLY used for the loader method of LINUX.

> So my thought (or my understanding from your wording) was that there
> seems to be possible that one kernel-like directive might have one
> behavior (or capabilities) regarding keeppxe and other kernel-like
> directives might behave differently than the first one. If my
> interpretation (of your wording) were to be correct, then it would
> imply that there are differences between some kernel-like directives
> (other than the different behaviors regarding file name extensions). If
> such different behavior (in response or in relation to using the
> keeppxe option) exists in some kernel-like directives, I wasn't aware
> of it and your sentence confused me.
>
> I was asking for clarification, because my aforementioned
> interpretation of your words seems to be contradicting my prior
> understanding of kernel-like directives.
>
> Hopefully, this email clarifies my question.
>
> TIA,
> Ady.
>
> PS: Considering that linux.c32 is based on the LINUX directive (which
> is a kernel-like directive) with some additions, perhaps linux.c32
> should (also) get the capability of parsing / using keeppxe?

Actually, reverse.  There was an older LINUX method but, instead of
outright replacement, someone choose to implement the C-based loader
functions with linux.c32 then later move/copy that code into the core.
This allowed testing/debugging of the new C-based functions and
comparison against the old ASM code.  So the loader method of LINUX is
based off of the linux.c32 module.

--
-Gene


More information about the Syslinux mailing list