Thorsten Glaser
2014-Nov-06 14:23 UTC
[syslinux] No thanks for breaking third-party applications
Hi *, I was just debugging why TFTP booting did not work any more on a system that had pxelinux.0 was updated. ?Since version 5.00, support for 16-bit COMBOOT modules has been dropped, and c32 modules switched from the COM32 object format to ELF.? Ugh. Well, updating the *.c32 files was enough to make the Linux discless thingy work again. BUT! The MirBSD bootloader actually took advantage of COMBOOT to provide access to SYSLINUX storage and other things. It was integrating nicely. Why did you take this away? I?m not amused. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Geert Stappers
2014-Nov-06 18:17 UTC
[syslinux] comboot use cases WAS: No thanks for breaking third-party applications
On Thu, Nov 06, 2014 at 03:23:49PM +0100, Thorsten Glaser wrote:> ???Since version 5.00, support for 16-bit COMBOOT modules has been > dropped, and c32 modules switched from the COM32 object format to ELF.??? > > The MirBSD bootloader actually took advantage of COMBOOT to > provide access to SYSLINUX storage and other things. It was > integrating nicely.Please tell more about that COMBOOT use case.> Why did you take this away?I don't know. Neither I don't know what kind of extras the COMBOOT modules have / had.> I???m not amused.We got that message. So now let's focus on wanted functionality.> > bye, > //mirabilos > -- > Yes, I hate users and I want them to suffer. > -- Marco d'Itri on gmane.linux.debian.devel.general >Let me add a smiley on that (hopefully random generated) signature :-) ;-) Groeten Geert Stappers -- Leven en laten leven
Dean Graff
2014-Nov-06 23:26 UTC
[syslinux] No thanks for breaking third-party applications
mira, I the maker of statix BSD, statix linux and statix ctools. Please stop being so rude and raping hard working foss projects for all they are worth. You wrote mksh, you write mirbsd, be a little less lazy and use the skills that we all trained you with for free -- to contribute back to foss. Ie; repair the functionality yourself, and then give it to us. We are not here to help you sell your products. I am equally not amused by your behaviour. - Graff On Thu, Nov 6, 2014 at 8:23 AM, Thorsten Glaser <t.glaser at tarent.de> wrote:> Hi *, > > I was just debugging why TFTP booting did not work any more > on a system that had pxelinux.0 was updated. > > "Since version 5.00, support for 16-bit COMBOOT modules has been > dropped, and c32 modules switched from the COM32 object format to ELF." > > Ugh. Well, updating the *.c32 files was enough to make the > Linux discless thingy work again. BUT! > > The MirBSD bootloader actually took advantage of COMBOOT to > provide access to SYSLINUX storage and other things. It was > integrating nicely. Why did you take this away? I'm not amused. > > bye, > //mirabilos > -- > Yes, I hate users and I want them to suffer. > -- Marco d'Itri on gmane.linux.debian.devel.general > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux
Gene Cumm
2014-Nov-06 23:50 UTC
[syslinux] No thanks for breaking third-party applications
snipping... On Thu, Nov 6, 2014 at 9:23 AM, Thorsten Glaser <t.glaser at tarent.de> wrote:> The MirBSD bootloader actually took advantage of COMBOOT to > provide access to SYSLINUX storage and other things. It was > integrating nicely. Why did you take this away? > > bye, > //mirabilosThough not official, I can try to offer some insight. The branch that lead to the 5.xx series was known as elflink and involved rewriting in C essentially everything that was in ASM (though there's still some ASM glue). Preserving COMBOOT functionality would require rewriting its code also in C. Two reasons for the rewrite in C are increased maintainability and portability for the (then) upcoming multiarch build in the firmware branch. This added EFI32 and EFI64 functionality. I believe some reasons the COMBOOT functionality was not rewritten were a perceived low benefit for the likely large cost and time limits. In my (unofficial) opinion, if it were reimplemented, it would be best as a library (ie libcbt.c32) which would eliminate the payload from the core and make it a little easier to only build for BIOS (the sole possible platform). -- -Gene