|
From: Peter L. <P.L...@sy...> - 2002-11-21 21:00:57
|
> I just took a look at syslinux and all it really uses is are the PXE > UDP functions, that are currently implemented for freebsd support. > Though I believe it uses the 16bit API entry points. There's actually no particular reason AFAICS that syslinux needs to use pxe. It could be ported as an etherboot "menu module", to sit on top of Etherboot's drivers so that people who want syslinux behaviour can have a syslinux-in-firmware (which even has an IDE driver, dammit). > So with a little care I think etherboot could implement pxe without > many changes. The task list would look like: > > The todo list would be: > - Working 16bit PXE/32bit PXE glue code. > - Working raw download driver. > - [optional] PXE hacked DHCP. > - [optional] PXE TFTP. > - [optional] PXE UNDI compatibility. HPA has said that that the world needs a decent open source PXE implementation, and I'm inclined to agree, though possibly not for the same reasons. I'd have said that UNDI is the most essential bit - that is why people *want* PXE, I perceive - nic independent booting. They tend to use "PXE" as shorthand for "nic independent network boot". They are looking for "network in the BIOS", not a lecture on the ways in which PXE is broken. > Just in case someone is ambitious or has worries about shipping a > machine to someone who really wants PXE support. I don't want PXE support as such - I want open source firmware world domination, and supporting PXE is an important step on that road. Unbiased firmware which loads whatever environment is required to support the OS is the aim; LinuxBIOS and Adam Sulmicki's PC BIOS work can provide this for those who need an MS environments, and EB with PXE allows them to boot from the net. The daft thing is that it should not be hard to provide even comitted MS users with far *better* firmware than they get from the likes of Award, and real choice about what sits on the mobo. And then, once open-source code actually has control, the prospects are *really* interesting. :) |
|
From: Peter L. <P.L...@sy...> - 2002-11-22 16:10:15
|
Eric B said: > I don't even want to go into how bad I think in principle a syscall > layer in the firmware is, and it is definitely not something I would > design for. But at the same time I think there is value in being > compatible, especially if it the implementation is trivial and has no > real maintenance burden. I'm suggesting only that the syslinux behaviour (tftp a config file) is maintained at the highest level. As this simply uses dhcp and tftp, this should be exactly the kind of thing that the separate EB menu stuff does now, yes? > Give me a broader survey, but neither pxelinux nor the freebsd loader > use the UNDI layer. And UNDI is an optional part of PXE for the > Itanium. If an unmodified pxelinux would run under etherboot there > are plenty of people who would say that is PXE and not care about > the technical details. Sorry, too many acronyms beginning with 'U'. Yes, Eric, you are right; the question is which *interfaces* to export. I am embarrased to be guilty of the same mistake I described earlier, reading "UNDI" as the nic independence itself and forgetting that the "I" means "interface". Duh. People need the driver, not the driver API. One needs UNDI only if NOT using UDP; you observe that pxe clients only use the UDP PXE interface, and are suggesting just supporting UDP in the first instance. It would be interesting to know what NTLOADER and other things use. > > I don't want PXE support as such - I want open source firmware world > > domination, and supporting PXE is an important step on that road. > > Unbiased firmware which loads whatever environment is required to > > support the OS is the aim; LinuxBIOS and Adam Sulmicki's PC BIOS work > > can provide this for those who need an MS environments, and EB with PXE > > allows them to boot from the net. > > You want to take the torch on this one? It is on my wishlist, but > I really don't have time to pursue any of this right now. I think it's really interesting; at the moment, all I can really do is propagandise. I've been watching EB, LinuxBIOS and friends and also thinking about what vmware, User Mode Linux, bochs are doing for virtualisation. I like Ollie Lho's suggestion of "Omniboot" to described the mass of booting related stuff. This could really be something. |
|
From: <ebi...@ln...> - 2002-11-22 07:01:10
|
Peter Lister <P.L...@sy...> writes: > > I just took a look at syslinux and all it really uses is are the PXE > > UDP functions, that are currently implemented for freebsd support. > > Though I believe it uses the 16bit API entry points. > > There's actually no particular reason AFAICS that syslinux needs to use > pxe. It could be ported as an etherboot "menu module", to sit on top of > Etherboot's drivers so that people who want syslinux behaviour can have > a syslinux-in-firmware (which even has an IDE driver, dammit). I don't even want to go into how bad I think in principle a syscall layer in the firmware is, and it is definitely not something I would design for. But at the same time I think there is value in being compatible, especially if it the implementation is trivial and has no real maintenance burden. > > So with a little care I think etherboot could implement pxe without > > many changes. The task list would look like: > > > > The todo list would be: > > - Working 16bit PXE/32bit PXE glue code. > > - Working raw download driver. > > - [optional] PXE hacked DHCP. > > - [optional] PXE TFTP. > > - [optional] PXE UNDI compatibility. > > HPA has said that that the world needs a decent open source PXE > implementation, and I'm inclined to agree, though possibly not for the > same reasons. > > I'd have said that UNDI is the most essential bit - that is why people > *want* PXE, I perceive - nic independent booting. They tend to use "PXE" > as shorthand for "nic independent network boot". They are looking for > "network in the BIOS", not a lecture on the ways in which PXE is broken. Give me a broader survey, but neither pxelinux nor the freebsd loader use the UNDI layer. And UNDI is an optional part of PXE for the Itanium. If an unmodified pxelinux would run under etherboot there are plenty of people who would say that is PXE and not care about the technical details. > > Just in case someone is ambitious or has worries about shipping a > > machine to someone who really wants PXE support. > > I don't want PXE support as such - I want open source firmware world > domination, and supporting PXE is an important step on that road. > Unbiased firmware which loads whatever environment is required to > support the OS is the aim; LinuxBIOS and Adam Sulmicki's PC BIOS work > can provide this for those who need an MS environments, and EB with PXE > allows them to boot from the net. You want to take the torch on this one? It is on my wishlist, but I really don't have time to pursue any of this right now. Eric |
