On Friday 11 February 2005 03:42, Rob Landley wrote:
> On Thursday 10 February 2005 09:33 pm, Blaisorblade wrote:
> Gee, Red Hat, the distro that brought us gcc 2.96, is now having ld throw
> assertion failures trying to build UML. It's nice to see tradition
> maintained...
No, this one is Gentoo
On Thursday 10 February 2005 09:33 pm, Blaisorblade wrote:
> > Sorry, meant UML.
> >
> > (I have a cold.)
>
> Best wishes for your health... (please, someone translate this to real
> English :-) )
Oh, it's real english. (Or at least it seems so to someone who just burned
french toast to charcoal
This time, I've announced this on my homepage, since I'd like to get some more
testing.
Things I've forgot:
* make it apply easily on Fedora kernels.
This should simply mean moving the TIF_SYSCALL_EMU to place no.8, to leave a
slot free for _DB7, needed for 4g4g or something like that and using
Stian, can you please read this and provide some help? The point of interest
for you is ***MARKED***
On Friday 11 February 2005 01:31, Rob Landley wrote:
> On Thursday 10 February 2005 10:44 am, Blaisorblade wrote:
> > > And requiring SKAS mode to use uclibc
> >
> > uclibc doesn't allow static li
[EMAIL PROTECTED] said:
> Where had that come from? The patch I've done is on ftp://
> ftp.linux.org.uk/pub/people/viro/UML-kbuild. I don't see that chunk
> in there. The closest I can find is
My fault. There were some clashes with other patches in my tree, and that
was the result of fixing on
On Thursday 10 February 2005 10:44 am, Blaisorblade wrote:
> > And requiring SKAS mode to use uclibc
>
> uclibc doesn't allow static linking? It's strange...
Sorry, meant UML. (I have a cold.)
> > is roughly equivalent to requiring a
> > kernel module in order to work.
>
> Ok, are you able to f
On Thursday 10 February 2005 21:11, Al Viro wrote:
> On Thu, Feb 10, 2005 at 07:39:23PM +0100, Blaisorblade wrote:
> > First, Al, thanks a lot for succeeding in solving this... I had tried a
> > lot of time ago to make sure that O= worked... (I think that -j already
> > worked, unless somebody re-b
On Thu, Feb 10, 2005 at 08:16:52PM +0100, Blaisorblade wrote:
> On Thursday 10 February 2005 20:04, Al Viro wrote:
> > On Thu, Feb 10, 2005 at 07:39:23PM +0100, Blaisorblade wrote:
> > > 3) I don't understand how vmlinux.lds.S is created... it's a symlink, but
> > > it's created nowhere after the p
On Thu, Feb 10, 2005 at 07:39:23PM +0100, Blaisorblade wrote:
> First, Al, thanks a lot for succeeding in solving this... I had tried a lot
> of
> time ago to make sure that O= worked... (I think that -j already worked,
> unless somebody re-broke it after I fixed that). Plus you fix a lot of oth
Ok, the first thing is the cleanup of PTRACE_SYSEMU_SINGLESTEP. I've carefully
moved the handling to go near to PTRACE_SINGLESTEP. As said, it's needed also
to port this stuff to 2.6.10 easily (wrt the introduction of
{clear,set}_singlestep).
The patch is attached both with only my changes, to
On Thursday 10 February 2005 20:04, Al Viro wrote:
> On Thu, Feb 10, 2005 at 07:39:23PM +0100, Blaisorblade wrote:
> > 3) I don't understand how vmlinux.lds.S is created... it's a symlink, but
> > it's created nowhere after the patch - maybe I overlook something, maybe
> > you didn't do "make clean
On Thu, Feb 10, 2005 at 07:39:23PM +0100, Blaisorblade wrote:
> 3) I don't understand how vmlinux.lds.S is created... it's a symlink, but
> it's
> created nowhere after the patch - maybe I overlook something, maybe you
> didn't do "make clean" and retest.
Not a symlink anymore. It's right ther
First, Al, thanks a lot for succeeding in solving this... I had tried a lot of
time ago to make sure that O= worked... (I think that -j already worked,
unless somebody re-broke it after I fixed that). Plus you fix a lot of other
stuff.
There are (at least) two bugs to fix about this patch, plus
From: Bodo Stroesser <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
In linux 2.6, PTRACE_SETOPTIONS is redefined to 0x4200, while the old 2.4
value (21) is still available as PTRACE_OLDSETOPTIONS.
So, if UML uses PTRACE_SETOPTIONS, an UML-kernel built on a 2.6 won't run on a
2.4 ho
From: Jeff Dike <[EMAIL PROTECTED]>
Fix a typo in the Makefile cleanup merged earlier, which causes compile
failures in some edge cases.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.11-paolo/arch/um/Makefile |4 ++--
1 files changed, 2 insertions(+), 2 de
On Thursday 10 February 2005 15:16, Rob Landley wrote:
> On Thursday 10 February 2005 06:31 am, Blaisorblade wrote:
> > 2.6.9 is unusable on a >=2.6.9 host, however (yes, it's ironic), but
> > 2.6.9-bs is usable in most cases (especially for SKAS mode - you Rob have
> > hit some bug in TT mode, how
On Thursday 10 February 2005 06:31 am, Blaisorblade wrote:
> 2.6.9 is unusable on a >=2.6.9 host, however (yes, it's ironic), but
> 2.6.9-bs is usable in most cases (especially for SKAS mode - you Rob have
> hit some bug in TT mode, however for people using SKAS mode it's ok. And
> sadly, most peo
On Wednesday 09 February 2005 18:33, Gerd Knorr wrote:
> > > Anyone looked at 2.6.11-rc1 for the host? Some more ptrace cleanups
> >
> > I've already solved those conflict earlier on -rc1 (not tested) but I
> > didn't polish it out yet... if you are in a hurry, I can finish it and
> > post the res
On Thursday 10 February 2005 12:42, [EMAIL PROTECTED] wrote:
> > Also, the code inside UML should absolutely support it (from the code I
> > don't
> > see any problem), at least for the x86 UML.
>
> modify_ldt is a x86 syscall aswell, so it will only appear in x86/x86_64
> umls.
Yes, agreed... x86
> Also, the code inside UML should absolutely support it (from the code I
> don't
> see any problem), at least for the x86 UML.
modify_ldt is a x86 syscall aswell, so it will only appear in x86/x86_64
umls. It was implemented and used by dosemu project originally.
What actually uses this syscall
On Thursday 10 February 2005 04:40, Rob Landley wrote:
> On Wednesday 09 February 2005 10:38 am, [EMAIL PROTECTED] wrote:
> > --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 07:38 PST
> > --- Could someone please update me with the status of this bug? Are
> > there still problems
On Wednesday 09 February 2005 21:12, Wichmann, Mats D wrote:
> > As a quick reminder, Marion and Bill are trying to get
> >i386 fedora
> >core 3 running under uml (2.6.4, with the i386 emulation code) on ford
> >(x86_64).
Well, the problem is that UML for x86_64 is not yet complete, especially for
On Wednesday 09 February 2005 10:36, Dominik Hirt wrote:
> Hi
>
> Many thanks for your answer.
> So the problem exists only when module support is activated in the
> kernel of the uml, right?
Well, what I said is that on any UML the guest root can do everything on the
host as normal user (but ever
23 matches
Mail list logo
