Syslinux - Oct 2015 - Confusion on lpxelinux vs. gpxelinux vs. ipxe vs gpxe.

On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux
<syslinux at zytor.com> wrote:
> Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115
A fork is a fork, regardless the reasons behind it (yes, I have some
understanding in this case).  iPXE is based off of forking further
development as of a certain gPXE commit with some backporting of gPXE
development to iPXE.

-- 
-Gene

On Sat, Oct 24, 2015 at 08:04:08PM -0400, Gene Cumm
wrote:
> On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown wrote:
> 
> > Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115
> 
> A fork is a fork, regardless the reasons behind it (yes, I have some
> understanding in this case).
So take some time to elaborate that understanding and translate it to
this project.

Yes, I'm some what angry that the gPXE rename to iPXE is called a fork.
Where fork is considered a four letter word. I think forking is way
of how software evolves. Avoiding a fork is good, but not at all costs.

> iPXE is based off of forking further development as of a certain gPXE
> commit with some backporting of gPXE development to iPXE.
And all the heavy lifting done by mcb30, Michael Brown.
Yes, the mcb30 from the Etherboot project.


Groeten
Geert Stappers
-- 
Leven en laten leven
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: signature.asc
Type: application/pgp-signature
Grootte: 836 bytes
Omschrijving: Digital signature
URL :
<http://www.zytor.com/pipermail/syslinux/attachments/20151025/34fdd737/attachment.sig>

On 25/10/15 01:04, Gene Cumm wrote:
> On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux
> <syslinux at zytor.com> wrote:
>
>> Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115
>
> A fork is a fork, regardless the reasons behind it (yes, I have some
> understanding in this case).  iPXE is based off of forking further
> development as of a certain gPXE commit with some backporting of gPXE
> development to iPXE.
 From my perspective, a "fork" is when you take someone else's
code and
spin it off into a new project.  Taking what is primarily your own code 
and renaming it does not, for me, count as a "fork".  Maybe we're
just
using different definitions of the word.

Anyway, to answer the questions of substance in this thread:

There were some issues relating to iPXE real-mode operations that show 
up on pre-Westmere CPUs with newer (and stricter) versions of KVM.  This 
was fixed in a series of commits last year:

   http://git.ipxe.org/ipxe.git/commitdiff/6d4deee
   http://git.ipxe.org/ipxe.git/commitdiff/5a08b63
   http://git.ipxe.org/ipxe.git/commitdiff/c64747d
   http://git.ipxe.org/ipxe.git/commitdiff/bcfaf11

along with some patches to avoid unnecessary real-mode transitions 
entirely (e.g. by allowing the system timer tick interrupt to happen in 
protected mode).

A quick test just now under current KVM (running on a five-year-old Core 
i5) shows a download speed of around 1600Mbps sustained for 2.5GB of 
data downloaded from the VM host to the guest:

   http://ipxe.org/_media/screenshots/ipxe_speed.png


All of my GigE test hardware sustains 1000Mbps HTTP downloads under 
iPXE.  My 10GigE test hardware typically sustains somewhere in the 
region of 2000-3000Mbps (CPU-limited, on a very old Core2Duo CPU).  Any 
new iPXE driver developed commercially will be tested and expected to 
reach 1000Mbps or have good reasons for not doing so.


You can construct an ipxelinux.0 as an updated replacement for 
gpxelinux.0, to solve the problems relating to the old gPXE code present 
in gpxelinux.0.  However, there's not much motivation to do so. 
Instead, you should either use lpxelinux.0, or use iPXE itself.

Michael

Hi Michael,
Thanks for answering the substance of my questions. It looks like I should
be focussing on lpxelinux and taking a good look at iPXE itself.

Cheers,

Doug

On 25 October 2015 at 20:27, Michael Brown <mcb30 at ipxe.org> wrote:
> On 25/10/15 01:04, Gene Cumm wrote:
>
>> On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux
>> <syslinux at zytor.com> wrote:
>>
>> Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115
>>>
>>
>> A fork is a fork, regardless the reasons behind it (yes, I have some
>> understanding in this case).  iPXE is based off of forking further
>> development as of a certain gPXE commit with some backporting of gPXE
>> development to iPXE.
>>
>
> From my perspective, a "fork" is when you take someone else's
code and
> spin it off into a new project.  Taking what is primarily your own code and
> renaming it does not, for me, count as a "fork".  Maybe we're
just using
> different definitions of the word.
>
> Anyway, to answer the questions of substance in this thread:
>
> There were some issues relating to iPXE real-mode operations that show up
> on pre-Westmere CPUs with newer (and stricter) versions of KVM.  This was
> fixed in a series of commits last year:
>
>   http://git.ipxe.org/ipxe.git/commitdiff/6d4deee
>   http://git.ipxe.org/ipxe.git/commitdiff/5a08b63
>   http://git.ipxe.org/ipxe.git/commitdiff/c64747d
>   http://git.ipxe.org/ipxe.git/commitdiff/bcfaf11
>
> along with some patches to avoid unnecessary real-mode transitions
> entirely (e.g. by allowing the system timer tick interrupt to happen in
> protected mode).
>
> A quick test just now under current KVM (running on a five-year-old Core
> i5) shows a download speed of around 1600Mbps sustained for 2.5GB of data
> downloaded from the VM host to the guest:
>
>   http://ipxe.org/_media/screenshots/ipxe_speed.png
>
>
> All of my GigE test hardware sustains 1000Mbps HTTP downloads under iPXE.
> My 10GigE test hardware typically sustains somewhere in the region of
> 2000-3000Mbps (CPU-limited, on a very old Core2Duo CPU).  Any new iPXE
> driver developed commercially will be tested and expected to reach 1000Mbps
> or have good reasons for not doing so.
>
>
> You can construct an ipxelinux.0 as an updated replacement for
> gpxelinux.0, to solve the problems relating to the old gPXE code present in
> gpxelinux.0.  However, there's not much motivation to do so. Instead,
you
> should either use lpxelinux.0, or use iPXE itself.
>
> Michael
>


-- 

The big print giveth and the small print taketh away.

On Sun, Oct 25, 2015 at 5:27 AM, Michael Brown <mcb30 at ipxe.org>
wrote:
> On 25/10/15 01:04, Gene Cumm wrote:
>>
>> On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux
>> <syslinux at zytor.com> wrote:
>>
>>> Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115
>>
>>
>> A fork is a fork, regardless the reasons behind it (yes, I have some
>> understanding in this case).  iPXE is based off of forking further
>> development as of a certain gPXE commit with some backporting of gPXE
>> development to iPXE.
>
>
> From my perspective, a "fork" is when you take someone else's
code and spin
> it off into a new project.  Taking what is primarily your own code and
> renaming it does not, for me, count as a "fork".  Maybe we're
just using
> different definitions of the word.
A lot of people have a looser view.  The gPXE code was under the
EtherBoot project.  New project with same code led me to label it a
fork.  Development on gPXE could have continued (regardless what
actually happened).  I do not deny the amount of work you did for gPXE
(let the commit history speak for this).
> Anyway, to answer the questions of substance in this thread:
Thank you.
> You can construct an ipxelinux.0 as an updated replacement for gpxelinux.0,
> to solve the problems relating to the old gPXE code present in gpxelinux.0.
> However, there's not much motivation to do so. Instead, you should
either
> use lpxelinux.0, or use iPXE itself.
gPXE hasn't been removed mostly from history.  Not enough testing of
lpxelinux.0 has happened and been recognized to make it something that
feels like a good decision.

-- 
-Gene