similar to: New build code merged...

Okay, as of this point, I think klibc is in quite good shape; my testing so far is showing that it can be used as a drop-in replacement for the kernel root-mounting code. That being said, there is guaranteed to be breakage, for two reasons: a. There are several architectures which don't have klibc ports yet. Since I don't have access to them, I can't really do them, either.

If there is anything that you think should have been in Syslinux 4.04 which isn't there please holler now. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Are there anyone who has a machine on which the *current* version of SYSLINUX ends up with an inoperable USB keyboard, especially when using the menu system? I might have a workaround, but I don't have a system which exhibits the problem available to me at the moment, and I really don't want to put in a hack without knowing that it actually does anything... If you do have such a

I'm thinking it's time to release klibc-1.5; however, before releasing klibc-1.4.31 as klibc-1.5, I wanted to give a call to see if there is anything that either really needs to be done, or any bug reports I've missed... -hpa

Commit-ID: c3110b853f667d544717a9cdd6d96b1a2a7365bf Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=c3110b853f667d544717a9cdd6d96b1a2a7365bf Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Thu, 24 May 2012 07:43:31 -0700 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Thu, 24 May 2012 07:43:31 -0700 [klibc] sys/sysmacros.h: match glibc and

I'm going to try to push 4.05 out this week, so please holler if there is anything critical missing. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Hi all, I'm working on a klibc gcc wrapper, which of course needs to know where everything is installed to know where to pull stuff from. This means making a working "make install". My current thinking is to drop /usr/include/klibc, and instead put the whole tree under /usr/lib/klibc. In particular, I'd like to have: $(CROSS) is the cross-compilation prefix if any.

I have updated and pushed the klibc-kernel tree. "In theory" it should be a 1:1 replacement for any stock kernel, which kinit taking up the slack. Anyway, I haven't yet removed any in-kernel functionality, but that's hopefully coming; the in-kernel functionality won't be executed in either case. git://git.kernel.org/pub/linux/kernel/git/hpa/linux-2.6-klibc.git -hpa

I'm trying to do a full rebase (history clean) of the klibc kernel tree, and came across the following changesets between klibc 1.3.12 and .16: --- a/usr/klibc/arch/s390/syscall.c +++ b/usr/klibc/arch/s390/syscall.c @@ -11,6 +11,6 @@ long int __syscall_common(long int err) { if ((unsigned long)(err) < (unsigned long)(-125)) return err; - errno = err; +

Hello all, I really want to support vfork() in klibc, mostly because uClinux *has* to use it. Unfortunately vfork() isn't allowed to use the stack *at all* across the system call -- including return address -- which means it needs an assembly wrapper on most architectures. I have tried implementing wrappers for most architectures, but I don't know parisc or s390/s390x well enough,

On 09/08/2014 05:57 AM, Dejan Latinovic wrote: >> From: H. Peter Anvin [hpa at zytor.com] >> Sent: Friday, September 05, 2014 7:13 PM >> To: Dejan Latinovic; YunQiang Su; klibc at zytor.com; maximilian attems >> Subject: Re: [klibc] [PATCH] add mips64 support > >> Why copy the files rather than share them? > > Hi Peter, > here is new version of

On 07/14/2014 05:24 AM, Dejan Latinovic wrote: > > > Hello, > I apologize for a late response. > > > I have crated a new version of patch with mips64 support for klibc. > > > Here are some changes: > - archsetjmp.h has been reduced. > - Symbolic register names are fixed (asm.h). > - Some not needed parts were removed. > - crt0.S is fixed to work

Hi In run-init.c there is a minor bug which can cause major problems i.e. not able to boot systems with udev-enabled initramfs on systems with multiple cdrom drives. In nuke_dirent () in run-init.c the stat call should be replaced with a lstat call, else nuking symbolic links which have been created before the link target will fail. Was somewhat tricky to debug... The bug gets triggered by udev

On 12/26/2013 07:27 PM, Robin H. Johnson wrote: > (please CC me, I'm not on the klibc list, and I didn't get HPA's > response to my post). > > On Fri, Dec 27, 2013 at 12:24:34AM +0000, Thorsten Glaser wrote: >> H. Peter Anvin dixit: >>> You should be using the output of "make headers_install" to build klibc. > That makes easy cross-building a

On 11/08/2013 09:12 AM, Steve Capper wrote: > diff --git a/usr/klibc/lstat.c b/usr/klibc/lstat.c > new file mode 100644 > index 0000000..0282eec > --- /dev/null > +++ b/usr/klibc/lstat.c > @@ -0,0 +1,17 @@ > +#include <fcntl.h> > +#include <unistd.h> > +#include <sys/types.h> > +#include <sys/stat.h> > +#include <sys/syscall.h> > +

Hello, Since klibc dash last merge is a bit dated yesterday I resyncronised the dash in klibc repo from dc2bc17c7bbe3188cfb0c695dc472b39bcf0b27a up to ec2c84d3c4dba4b74440d72bdd1de416a9acd2a9 commit. Please test it: git://git.kernel.org/pub/scm/libs/klibc/klibc-queue.git http://git.kernel.org/?p=libs/klibc/klibc-queue.git;a=shortlog Without objections this will land in klibc-1.5.23. It got

Kay Sievers wrote: > Hi, > this simple program compiled with klibc: > > #include <stdio.h> > int main(int argc, char* argv[]) > { > setenv("TESTENV", "happy", 1); > printf("TESTENV='%s'\n", getenv("TESTENV")); > } > > prints: > > ./env > TESTENV='(null)' > >

On 11/08/2013 09:12 AM, Steve Capper wrote: > + > +/* > + * x19-x28 are callee saved, also save fp, lr, sp. > + * d8-d15 are also callee saved. > + */ > + > +struct __jmp_buf { > + uint64_t __gregs[13]; > + uint64_t __fpregs[8]; > +}; > + Since the index of these arrays have no connection with what is stored in them, they should be named fields in the structure,

I finally got some time to work through the klibc patch queue... however, since I have been AWOL so long I might have dropped patches. If someone could take a quick look at the git tree before I push a new version out that would be great. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Well, as of right now, both Linus and Andrew have rejected klibc in the kernel based on "it doesn't add anything new" (Linus) and "lack of interest" (Andrew). It seems that there is little hope of getting it into the kernel any time soon, unless there is additional features, and/or people start actively asking for it. I would appreciate hearing suggestions. The