similar to: No thanks for breaking third-party applications

On Tue, 2 Dec 2014, H. Peter Anvin wrote: > This is the default unless the "quiet" option is set. Hmm. tglaser at luna:/srv/tftp $ fgrep -ri quiet . Binary file ./hdt.c32 matches Binary file ./ldlinux.c32 matches Binary file ./vmlinuz matches Binary file ./linux.c32 matches Binary file ./debian-installer/jessie/amd64/linux matches Binary file ./debian-installer/jessie/i386/linux

Hi, I still have the question: when I have an environment that uses vesamenu, for example on PXE, how do I configure it so that, for some of the menu entries, it switches back to the text mode (03h) before handing off to the next bootloader / kernel? Thanks, //mirabilos -- tarent solutions GmbH Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/ Tel: +49 228 54881-393 ? Fax: +49 228

On Fri, 5 Dec 2014, Gene Cumm wrote: > >> mostly in C and be BIOS-only) or making the MirOS kernel act like > >> either an MBOOT kernel or a Linux kernel (for their boot protocols), The MirBSD _bootloader_ (not kernel) can act as a Multiboot kernel. It can then use disc access (not PXE), or you can pass it the ?real? kernel, but also e.g. configuration files, as Multiboot

This uses time, ASLR and pid for randomisation. (Closes: #516774) Signed-off-by: Thorsten Glaser <tg at mirbsd.org> --- usr/include/stdlib.h | 2 + usr/klibc/Kbuild | 2 +- usr/klibc/mkstemp.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 96 insertions(+), 1 deletions(-) create mode 100644 usr/klibc/mkstemp.c diff --git a/usr/include/stdlib.h

Steve Capper dixit: >> Do we need the fpregs saved even though klibc doesn't do fp? >For gcc targetting Aarch64, We can only guarantee that d8-d15 are >left alone when -mgeneral-regs-only is supplied for building klibc >and any software linked against klibc. I would much prefer to We can enforce this in klcc, just like -mregparm=3 is used by the i386 target. bye, //mirabilos

Hi, is there a DD-accessible porterbox somewhere (slow would be ok, as this is smallish software) with an up-to-date sid (enough to install the recently-built libklibc-dev 2.0~rc5-1 and all other B-D of mksh 40.9.20120518-1, as well as strace and gdb-minimal)? Similarily to http://www.zytor.com/pipermail/klibc/2012-May/003229.html I found klibc-compiled programmes on Alpha to fail (SIGSEGV

Hello, how would I go porting llvm-gcc-4.2 to an “unknown” platform, i.e. MirBSD? For regular gcc, I’d have to add stuff to gcc/gcc/config/ and patch quite some configure scripts, but seeing that llvm-gcc uses LLVM for target specific stuff, how much of this still applies? cpp defines and startup files at the least, probably, for the com- piler driver… Which dependencies does llvm-gcc-4.2 have,

On Thu, 4 Dec 2014, Gene Cumm wrote: > Ady has an excellent point. Try the following instead: > > LABEL test > MENU LABEL test > COM32 pxechn.c32 > APPEND pxebsd.0 Thanks, that works! How do I use that in the generic case? The ?pxebsd.0? file can be called as? ? PXE loader ? COMBOOT (16-bit) ? DOS .COM ? Multiboot (although it switches back to 16-bit mode

On Fri, 5 Dec 2014, Ady wrote: > A link to original documentation is very useful. Links to manpages > and/or to CVSweb are both fine. Some users might prefer the man page > (which might or might not be up-to-date and/or enough), and the CVSweb > content might be valuable for others. OK, sure. The sources are mostly in https://www.mirbsd.org/cvs.cgi/src/sys/arch/i386/stand/ (boot/

Hi sh4 porters, I?ve just fixed a regression of klibc to build from source on sh4 using the sumotsu.debian.net porterbox (thanks for making one available) and found a problem with your archi- tecture: all binaries built with klibc (shared and static) get a SIGILL (illegal instruction). I suspect that different CFLAGS are needed. Please, someone, have a look at it; a release of klibc 2.0 upstream

On 12/02/2014 06:48 AM, Thorsten Glaser wrote: > Hi, > > I still have the question: when I have an environment that uses > vesamenu, for example on PXE, how do I configure it so that, for > some of the menu entries, it switches back to the text mode (03h) > before handing off to the next bootloader / kernel? > This is the default unless the "quiet" option is set.

On Fri, 5 Dec 2014, Ady wrote: > > > If so: http://www.syslinux.org/wiki/index.php/Mboot.c32 > > > > I?m not permitted to edit either that page or its talk page. > > Do I submit the content addition here, then? > > Please do. Okay, MediaWiki syntax docs follow. Note I have tested those only a bit, and not within the vesamenu context, but if mboot.c32 resets to

Hi, after changing mksh to no longer use mkstemp, I decided to try and build mksh-static with klcc on most platforms, in Debian. Here are the results by Debian architecture: alpha (4) fails amd64 works armel works armhf (3) fails i386 works ia64 works m68k (1) workaround mips works mipsel works powerpc (2) fails ppc64 works (!) s390 works s390x works sparc works Architectures not listed either

On Thu, 2014-12-04 at 21:26 -0500, Gene Cumm wrote: > > Thanks, that works! How do I use that in the generic case? > > The ?pxebsd.0? file can be called as? > > > > ? PXE loader > > ? COMBOOT (16-bit) > > ? DOS .COM > > ? Multiboot (although it switches back to 16-bit mode immediately) > > ? from its own bootsector, if installed on disc (blocklist)

Tanya M. Lattner dixit: >LLVMers, > >The 2.4 pre-release (v2) is available for testing: >http://llvm.org/prereleases/2.4/ Is it correct that there is no matching clang distfile? A checkout of clang r58548 does not build with the prerelease, seems to require a newer version of llvm-current. (But then, maybe it’d be best anyway if I port llvm-current to MirBSD, because it’ll be easier

tags 516774 = patch tags 516294 = upstream thanks Hi! Please find attached a diff closing #516774 by adding mkstemp(3), again with a minimalistic pseudo-arc4random(3) behind it. I?ve revisited the code. An mkstemp testsuite from the ?net shows it works, except for not caring how many ?X?en are in the template. Addressing #516294, it allows compiling and linking an mksh from today?s CVS against

hpa at zytor.com dixit: >syscall(3) is not implemented by design, because it is silently broken >on many architectures (mainly 32-bit ones.) It?s also where most libcs break on various ports most often, because it?s surprisingly tricky to get right. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on;

> On Fri, 5 Dec 2014, Ady wrote: > > > > > If so: http://www.syslinux.org/wiki/index.php/Mboot.c32 > > > > > > I?m not permitted to edit either that page or its talk page. > > > Do I submit the content addition here, then? > > > > Please do. > > Okay, MediaWiki syntax docs follow. Note I have tested those > only a bit, and not

Hi, number three, where I first thought it was a GCC bug but is apparently bad code in klibc. Submitted with permission: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533#c6 Patch attached again (sorry) not just because that is easier with my mail system but also to keep original author intact. bye, //mirabilos -- > emacs als auch vi zum Kotzen finde (joe rules) und pine f?r den einzig >

Hi, after a year, I decided to hack on klibc again. I?ve reworked both the patch to add mkstemp(), discussing to use AT_RANDOM as cheap entropy source on IRC (if there will ever be another entropy consumer, I can quickly write a minimal arc4random() seeded from it, as it has only 16 octets), capable of making a working mksh (static and shared) on amd64/xen, and the m68k support code, leading to