Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: syslinux: users

SYSLINUX 3.70-pre1: development release

 

 

syslinux users RSS feed   Index | Next | Previous | View Threaded


hpa at zytor

Feb 27, 2008, 1:55 PM

Post #1 of 9 (10169 views)
Permalink
SYSLINUX 3.70-pre1: development release

Hi all,

I have pushed out a prerelease of one of the development branches (I
currently have three development branches open), 3.70-pre1.

This release revamps a whole lot of internal APIs to support reading
files without knowing their length ahead of time. This is necessary in
order to support network protocols which do not advertise the transfer size.

The immediate user-visible change is that TFTP no longer requires the
server to support the "tsize" option; this has the interesting
consequence that it allows the use of a proxying TFTP server (e.g. a
TFTP->HTTP proxy) without the proxy having to buffer the entire file.

The ultimate plan, however, is to move HTTP support into pxelinux
itself. There are a couple of potential paths for implementing this;
the current plan is to do a joint development project with the gPXE
development team, to obtain a single product with all the features of
gPXE and PXELINUX combined. If that doesn't work out, however, I do
have a backup plan.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


gzp at papp

Feb 28, 2008, 2:12 AM

Post #2 of 9 (9775 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

* "H. Peter Anvin" <hpa [at] zytor>:

| I have pushed out a prerelease of one of the development branches (I
| currently have three development branches open), 3.70-pre1.

"compile hack in for older distros" not applied? ;-)

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


strange at nsk

Feb 28, 2008, 2:36 AM

Post #3 of 9 (9762 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

On Wed, Feb 27, 2008 at 01:55:44PM -0800, H. Peter Anvin wrote:
> Hi all,
>
> I have pushed out a prerelease of one of the development branches (I
> currently have three development branches open), 3.70-pre1.

Do you have a description of your current development branches, their
goals and whishlists?

--
lfr
0/0


hpa at zytor

Feb 28, 2008, 10:45 AM

Post #4 of 9 (9770 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

Gabor Z. Papp wrote:
> * "H. Peter Anvin" <hpa [at] zytor>:
>
> | I have pushed out a prerelease of one of the development branches (I
> | currently have three development branches open), 3.70-pre1.
>
> "compile hack in for older distros" not applied? ;-)
>

No, that'll get picked up by the next mainstream merge. Pull the git
tree and look at gitk if you want to see the exact flow.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


hpa at zytor

Feb 28, 2008, 10:53 AM

Post #5 of 9 (9784 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

Luciano Rocha wrote:
> On Wed, Feb 27, 2008 at 01:55:44PM -0800, H. Peter Anvin wrote:
>> Hi all,
>>
>> I have pushed out a prerelease of one of the development branches (I
>> currently have three development branches open), 3.70-pre1.
>
> Do you have a description of your current development branches, their
> goals and whishlists?
>

Here is a rough summary. I don't have a wishlist ready, but we can talk
about it:


nolen - eliminating any dependency on a priori length (3.70-pre*)

The intent here is make it easier to support arbitrary network
protocols, such as FTP and HTTP, as well as
TFTP-to-other-protocol proxies.


bcopyint - unify all the real mode/protected mode machinery

Right now, SYSLINUX has three separate pieces of machinery for
real mode/protected mode transition, each of which have their
own feature sets. This branch works on unifying them to a
single, compact, and full-featured set.

The longer term goal here is to enable ditching most of the rest
of the real-mode assembly code in favour of protected-mode C
code.


gptmbr - Booting from GPT

This is a branch to explore booting off disks formatted with GPT
partition tables rather than classical MS-DOS partition tables.
Most of the discussion about this has been on the GNU Parted
mailing list.

The GPT partition format is defined in the EFI spec, which of
course assumes you're booting under EFI. This being a somewhat
speculative thing (shall we say), we have had discussions about
booting GPT under BIOS. There are two possible ways: a
so-called hybrid partitioning scheme, and creating a native
GPT partitioning protocol; this explores the latter.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


hpa at zytor

Feb 28, 2008, 11:24 AM

Post #6 of 9 (9765 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

H. Peter Anvin wrote:
>
> Here is a rough summary. I don't have a wishlist ready, but we can talk
> about it:
>
>
> nolen - eliminating any dependency on a priori length (3.70-pre*)
>
> The intent here is make it easier to support arbitrary network
> protocols, such as FTP and HTTP, as well as
> TFTP-to-other-protocol proxies.
>
>
> bcopyint - unify all the real mode/protected mode machinery
>
> Right now, SYSLINUX has three separate pieces of machinery for
> real mode/protected mode transition, each of which have their
> own feature sets. This branch works on unifying them to a
> single, compact, and full-featured set.
>
> The longer term goal here is to enable ditching most of the rest
> of the real-mode assembly code in favour of protected-mode C
> code.
>

I should point out that I'm in a pretty advanced stage about discussing
doing a PXELINUX-gPXE hybrid with the gPXE development team. The
general idea is pretty much to remove everything below the COM32 level
and replace it with an enhanced version of gPXE. We're still working
out the details, but an initial analysis seems to indicate that it
should be technically entirely feasible. As part of that, a lot of C
code would have to be written which can be reused as part of a rewritten
SYSLINUX core for non-network media, too.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


strange at nsk

Feb 28, 2008, 11:49 AM

Post #7 of 9 (9773 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

On Thu, Feb 28, 2008 at 11:24:42AM -0800, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> > Here is a rough summary. I don't have a wishlist ready, but we can talk
> > about it:
> > nolen - eliminating any dependency on a priori length (3.70-pre*)
> > The intent here is make it easier to support arbitrary network
> > protocols, such as FTP and HTTP, as well as
> > TFTP-to-other-protocol proxies.
> > bcopyint - unify all the real mode/protected mode machinery
> > Right now, SYSLINUX has three separate pieces of machinery for
> > real mode/protected mode transition, each of which have their
> > own feature sets. This branch works on unifying them to a
> > single, compact, and full-featured set.
> > The longer term goal here is to enable ditching most of the rest
> > of the real-mode assembly code in favour of protected-mode C
> > code.
>
> I should point out that I'm in a pretty advanced stage about discussing
> doing a PXELINUX-gPXE hybrid with the gPXE development team. The general
> idea is pretty much to remove everything below the COM32 level and replace
> it with an enhanced version of gPXE. We're still working out the details,
> but an initial analysis seems to indicate that it should be technically
> entirely feasible. As part of that, a lot of C code would have to be
> written which can be reused as part of a rewritten SYSLINUX core for
> non-network media, too.

That is interesting. Myself, I've given some thought, but not much time,
to:

1. make syslinux a mini-os, with some basic operations (dir and file
ops, mem alloc, and line input/output). The loader would load a standard
elf file, and the current features would be implemented as shared
libraries.

2. add support for intel-vt/amd-v to memdisk, to allow emulation of
devices even under linux/windows.

3. com32 module for loading linux kernels directly from rpms or debs,
with the option of keeping the contents of the package as part of the
initramfs.

Of the three, the last is the simpler and less intrusive, so I've been
playing with it when I can. But lately I'm just battling with the
current buildsystem trying to build syslinux with a cross-compiler on my
OS X powerpc.

I'd suggest a list on the wiki of tasks that you believe are simple
enough for someone without much knowledge of syslinux internals, and
maybe compile a list of more arduous task for participation in google's
summer of code.

Regards,
Luciano Rocha
>
> -hpa
>

--
lfr
0/0

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


jhutz at cmu

Feb 28, 2008, 1:11 PM

Post #8 of 9 (9790 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

--On Thursday, February 28, 2008 11:24:42 AM -0800 "H. Peter Anvin"
<hpa [at] zytor> wrote:

> H. Peter Anvin wrote:
>> The longer term goal here is to enable ditching most of the rest
>> of the real-mode assembly code in favour of protected-mode C
>> code.

This scares me, a lot more than it used to. Recently I've run into a
number of systems on which the USB keyboard emulation stops working when
you switch into 32-bit protected mode. I've been able to work around this
using a comboot program which detects the offending machines and either
offers to downgrade the BIOS or drops back into the CLI rather than running
a com32 menu program. I don't expect this approach to have much effect if
PXELINUX itself is mostly a 32-bit protected mode program.

Unless you're planning on including a USB stack...

> I should point out that I'm in a pretty advanced stage about discussing
> doing a PXELINUX-gPXE hybrid with the gPXE development team.

This has also made me nervous for some time, but I can't quantify why, so
I'll continue to wait and see.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.


hpa at zytor

Feb 28, 2008, 3:51 PM

Post #9 of 9 (9778 views)
Permalink
Re: SYSLINUX 3.70-pre1: development release [In reply to]

Jeffrey Hutzelman wrote:
> --On Thursday, February 28, 2008 11:24:42 AM -0800 "H. Peter Anvin"
> <hpa [at] zytor> wrote:
>
>> H. Peter Anvin wrote:
>>> The longer term goal here is to enable ditching most of the rest
>>> of the real-mode assembly code in favour of protected-mode C
>>> code.
>
> This scares me, a lot more than it used to. Recently I've run into a
> number of systems on which the USB keyboard emulation stops working when
> you switch into 32-bit protected mode. I've been able to work around this
> using a comboot program which detects the offending machines and either
> offers to downgrade the BIOS or drops back into the CLI rather than running
> a com32 menu program. I don't expect this approach to have much effect if
> PXELINUX itself is mostly a 32-bit protected mode program.
>

I have only heard of one specific BIOS version of one specific Dell
machine. I probably could find a workaround for it if I had access to a
specimen, but I don't.

>> I should point out that I'm in a pretty advanced stage about discussing
>> doing a PXELINUX-gPXE hybrid with the gPXE development team.
>
> This has also made me nervous for some time, but I can't quantify why, so
> I'll continue to wait and see.

Any large changes has the potential to break stuff.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX [at] zytor
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

syslinux users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.