[uml-devel] Re: merge status

[uml-devel] Re: merge status

[Rob Landley]

Linus said this:

> I think one reason -mm has worked so damn well (apart from you being "The
> Calmest Man on Earth"(tm)) is because it's essentially been that buffer
> for anything non-trivial. Sometimes the "n+2" has been a lot more than
> "n+2" in fact, and that's often good.
>
> (And at the same time, -mm has enough visibility that it doesn't drive
> developers crazy even when the "n+2" ends up being "n+5" or somethiing).
>
> I'd _hope_ that the same kind of situation could work for some of the
> majos subsystem git trees too: where the maintainer tree is well enough
> known that it gets sufficient coverage for that area that a "+2" approach
> for merging into the default kernel is practical.
>
> I also think it certainly _should_ be possible for the big areas that have
> well-defined target audiences.

And so I thought a bit about what that tree would be for UML (-mm?  -bb?) and 
decided "it's gotta be Jeff's tree as defined by 
user-mode-linux.sf.net/patches.html", so I grabbed the big rolled up tarball 
there that applies on top of 2.6.15-rc1:
http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.15-rc1/patches.tar

And applied them all (in series order) with a for loop.

I used the following mini-config (using the new mechanism where if you put a 
mini-config in the file "allno.config" and run "make ARCH=um allnoconfig", 
you get a config with just this switched on, plus any required dependencies.  
Neat, eh?)

CONFIG_MODE_SKAS=y
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_SYSCTL=y
CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_UBD=y
CONFIG_TMPFS=y
CONFIG_SWAP=y
CONFIG_LBD=y
CONFIG_EXT2_FS=y
CONFIG_PROC_FS=y

The build broke on the first file it tried to compile:

  CHK     include/linux/version.h
gcc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing 
-fno-common -ffreestanding -O2     -fomit-frame-pointer  -D__arch_um__ 
-DSUBARCH=\"i386\" -Iarch/um/include  
-I/home/landley/newbuild/firmware-build/sources/packages/linux-2.6.14/arch/um/include/skas 
-Dvmap=kernel_vmap -Din6addr_loopback=kernel_in6addr_loopback 
-Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask  -U__i386__ -Ui386 
-march=i686 -mpreferred-stack-boundary=2 -D_LARGEFILE64_SOURCE    -nostdinc 
-isystem /usr/lib/gcc-lib/i486-linux/3.3.5/include -D__KERNEL__ -Iinclude  
-include include/linux/autoconf.h -S -o arch/um/kernel-offsets.s 
arch/um/sys-i386/kernel-offsets.c
In file included from include/asm/thread_info.h:12,
                 from include/linux/thread_info.h:21,
                 from include/linux/spinlock.h:53,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/um/sys-i386/kernel-offsets.c:3:
include/asm/processor.h:19: error: field `tls' has incomplete type
In file included from arch/um/include/um_mmu.h:17,
                 from include/asm/mmu.h:9,
                 from include/linux/sched.h:23,
                 from arch/um/sys-i386/kernel-offsets.c:3:
/home/landley/newbuild/firmware-build/sources/packages/linux-2.6.14/arch/um/include/skas/mmu-skas.h:19: 
error: syntax error before "uml_ldt_t"
/home/landley/newbuild/firmware-build/sources/packages/linux-2.6.14/arch/um/include/skas/mmu-skas.h:19: 
warning: no semicolon at end of struct or union
In file included from include/asm/mmu.h:9,
                 from include/linux/sched.h:23,
                 from arch/um/sys-i386/kernel-offsets.c:3:
arch/um/include/um_mmu.h:25: error: field `skas' has incomplete type
make: *** [arch/um/kernel-offsets.s] Error 1

So I re-extracted 2.6.15-rc1, modified the for loop to apply them one at a 
time and build between each one, and ran that.

The build broke in a different way, after the very first patch 
(fix-stub-syscall6):

  CHK     usr/initramfs_list
  CC      arch/um/kernel/skas/clone.o
arch/um/kernel/skas/clone.c: In function `stub_clone_handler':
arch/um/kernel/skas/clone.c:35: error: aggregate value used where an integer 
was expected
make[2]: *** [arch/um/kernel/skas/clone.o] Error 1
make[1]: *** [arch/um/kernel/skas] Error 2
make: *** [arch/um/kernel] Error 2

So my question is: has anybody actually tried this patch series, and if so, 
_how_?  Am I doing something wrong?  (Building on ubuntu Horny Hedgehog with 
gcc 3.3.5)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> Linus said this:
> > I think one reason -mm has worked so damn well (apart from you being "The
> > Calmest Man on Earth"(tm)) is because it's essentially been that buffer
> > for anything non-trivial. Sometimes the "n+2" has been a lot more than
> > "n+2" in fact, and that's often good.
> >
> > (And at the same time, -mm has enough visibility that it doesn't drive
> > developers crazy even when the "n+2" ends up being "n+5" or somethiing).
> >
> > I'd _hope_ that the same kind of situation could work for some of the
> > majos subsystem git trees too: where the maintainer tree is well enough
> > known that it gets sufficient coverage for that area that a "+2" approach
> > for merging into the default kernel is practical.
> >
> > I also think it certainly _should_ be possible for the big areas that
> > have well-defined target audiences.
>
> And so I thought a bit about what that tree would be for UML (-mm?  -bb?)
> and decided "it's gotta be Jeff's tree as defined by
> user-mode-linux.sf.net/patches.html", so I grabbed the big rolled up
> tarball there that applies on top of 2.6.15-rc1:
> http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.15-rc1/patches.
>tar

Definitely Jeff's tree is a first filter for his work, but I've not seen it 
working a lot as a collector, especially for little fixes - but there it 
makes sense.

I tend to send directly to Andrew and he forwards them to Linus (in many cases 
so fast that I wonder if they appear in one -mm release), but I currently do 
not have a public tree.

> And applied them all (in series order) with a for loop.

Can I suggest using quilt for this (as it's more powerful and easy to use)?

Especially when you add other patches as compile fixups...

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 01:08, Blaisorblade wrote:
> On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > Linus said this:
> > > I think one reason -mm has worked so damn well (apart from you being
> > > "The Calmest Man on Earth"(tm)) is because it's essentially been that
> > > buffer for anything non-trivial. Sometimes the "n+2" has been a lot
> > > more than "n+2" in fact, and that's often good.
> > >
> > > (And at the same time, -mm has enough visibility that it doesn't drive
> > > developers crazy even when the "n+2" ends up being "n+5" or
> > > somethiing).
> > >
> > > I'd _hope_ that the same kind of situation could work for some of the
> > > majos subsystem git trees too: where the maintainer tree is well enough
> > > known that it gets sufficient coverage for that area that a "+2"
> > > approach for merging into the default kernel is practical.
> > >
> > > I also think it certainly _should_ be possible for the big areas that
> > > have well-defined target audiences.
> >
> > And so I thought a bit about what that tree would be for UML (-mm?  -bb?)
> > and decided "it's gotta be Jeff's tree as defined by
> > user-mode-linux.sf.net/patches.html", so I grabbed the big rolled up
> > tarball there that applies on top of 2.6.15-rc1:
> > http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.15-rc1/patche
> >s. tar
>
> Definitely Jeff's tree is a first filter for his work, but I've not seen it
> working a lot as a collector, especially for little fixes - but there it
> makes sense.
>
> I tend to send directly to Andrew and he forwards them to Linus (in many
> cases so fast that I wonder if they appear in one -mm release), but I
> currently do not have a public tree.

So there currently _is_ no one UML tree that people interested in the most 
recent UML developments can check out.  We basically have to wait until it 
hits mainline.

That's sad.  I think I'll stick with Jeff's tree as the closest I've come so 
far...

> > And applied them all (in series order) with a for loop.
>
> Can I suggest using quilt for this (as it's more powerful and easy to use)?
>
> Especially when you add other patches as compile fixups...

I'm not applying the other patches at the moment.  Right now I'm just trying 
to get Jeff's tree to build for me.  If I have time tonight I'm going to 
cherry-pick his patch list to see which ones I can get to compile, and give 
him the list of each one that breaks my build (and how).  I just mentioned 
that #2 of the recent 4 sent to Andrew broke the build for me, but that's not 
the only breakage I see from Jeff's tree.  (I currently have access to four 
different build environments.  I was focusing on the PLD x86-64 system I'm 
borrowing, but right now I'm focusing on my ubuntu laptop.  Then knoppix, and 
then my Linux From Scratch system with gcc 4.0.2 and uClibc...

Expect to be hearing from me a lot. :)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Friday 18 November 2005 08:17, Rob Landley wrote:
> On Friday 18 November 2005 01:08, Blaisorblade wrote:
> > On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > > Linus said this:

Btw, where does this quote come from?

> > > > I think one reason -mm has worked so damn well (apart from you being
> > > > "The Calmest Man on Earth"(tm)) is because it's essentially been that
> > > > buffer for anything non-trivial. Sometimes the "n+2" has been a lot
> > > > more than "n+2" in fact, and that's often good.
> > > >
> > > > (And at the same time, -mm has enough visibility that it doesn't
> > > > drive developers crazy even when the "n+2" ends up being "n+5" or
> > > > somethiing).

I don't quite get this +2/+5 discussion.

> > > > I'd _hope_ that the same kind of situation could work for some of the
> > > > majos subsystem git trees too: where the maintainer tree is well
> > > > enough known that it gets sufficient coverage for that area that a
> > > > "+2" approach for merging into the default kernel is practical.
> > > >
> > > > I also think it certainly _should_ be possible for the big areas that
> > > > have well-defined target audiences.

> > Definitely Jeff's tree is a first filter for his work, but I've not seen
> > it working a lot as a collector, especially for little fixes - but there
> > it makes sense.

> > I tend to send directly to Andrew and he forwards them to Linus (in many
> > cases so fast that I wonder if they appear in one -mm release), but I
> > currently do not have a public tree.

> So there currently _is_ no one UML tree that people interested in the most
> recent UML developments can check out.  We basically have to wait until it
> hits mainline.

Patches go in -mm first. Currently Andrew is often very quick at merging them.

Also, fixups tend to have less needs for testing - and they're often 
backported to -bs.

Also, I don't tend to merge big patches without first checking.

> That's sad.  I think I'll stick with Jeff's tree as the closest I've come
> so far...

> > > And applied them all (in series order) with a for loop.
> >
> > Can I suggest using quilt for this (as it's more powerful and easy to
> > use)?
> >
> > Especially when you add other patches as compile fixups...

> I'm not applying the other patches at the moment.  Right now I'm just
> trying to get Jeff's tree to build for me.

Which means applying your own fixups.

> If I have time tonight I'm 
> going to cherry-pick his patch list to see which ones I can get to compile,
> and give him the list of each one that breaks my build (and how).

I suggest quilt exactly because it automates one big task - managing the 
stacks of applied and unapplied patches. Will "patch" suggest you which patch 
is the top one? Quilt will. That's why I suggest you to try it.

> I just 
> mentioned that #2 of the recent 4 sent to Andrew broke the build for me,
> but that's not the only breakage I see from Jeff's tree.  (I currently have
> access to four different build environments.  I was focusing on the PLD
> x86-64 system I'm borrowing, but right now I'm focusing on my ubuntu
> laptop.  Then knoppix, and then my Linux From Scratch system with gcc 4.0.2
> and uClibc...

> Expect to be hearing from me a lot. :)

No problem... just be patient for fixes. And IMHO you shouldn't feel so shy 
about fixing such compile problems (no complaining!) I don't expect you to 
debug the stub problems, but the rest should be easier to work with.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 01:51, Blaisorblade wrote:
> On Friday 18 November 2005 08:17, Rob Landley wrote:
> > On Friday 18 November 2005 01:08, Blaisorblade wrote:
> > > On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > > > Linus said this:
>
> Btw, where does this quote come from?

Linux-kernel, last wednesday.

http://seclists.org/lists/linux-kernel/2005/Nov/3391.html

> > > > > I think one reason -mm has worked so damn well (apart from you
> > > > > being "The Calmest Man on Earth"(tm)) is because it's essentially
> > > > > been that buffer for anything non-trivial. Sometimes the "n+2" has
> > > > > been a lot more than "n+2" in fact, and that's often good.
> > > > >
> > > > > (And at the same time, -mm has enough visibility that it doesn't
> > > > > drive developers crazy even when the "n+2" ends up being "n+5" or
> > > > > somethiing).
>
> I don't quite get this +2/+5 discussion.

Context from the rest of the thread, which started here:
http://seclists.org/lists/linux-kernel/2005/Nov/3290.html

n is release number.  It was about the 2 week merge window and the fact that 
it's a fairly sucky time to do new development.  (It's for merging stuff that 
you already got to work, and then bug fixes.)  The -mm tree is for shaking 
bugs out of stuff that worked for you, but may not get merged into linus's 
tree immediately.

> > > > > I'd _hope_ that the same kind of situation could work for some of
> > > > > the majos subsystem git trees too: where the maintainer tree is
> > > > > well enough known that it gets sufficient coverage for that area
> > > > > that a "+2" approach for merging into the default kernel is
> > > > > practical.
> > > > >
> > > > > I also think it certainly _should_ be possible for the big areas
> > > > > that have well-defined target audiences.
> > >
> > > Definitely Jeff's tree is a first filter for his work, but I've not
> > > seen it working a lot as a collector, especially for little fixes - but
> > > there it makes sense.
> > >
> > > I tend to send directly to Andrew and he forwards them to Linus (in
> > > many cases so fast that I wonder if they appear in one -mm release),
> > > but I currently do not have a public tree.
> >
> > So there currently _is_ no one UML tree that people interested in the
> > most recent UML developments can check out.  We basically have to wait
> > until it hits mainline.
>
> Patches go in -mm first. Currently Andrew is often very quick at merging
> them.

The problem is (as the discussion brought up), Andrew's tree integrates many 
things.  If you want to test _just_ one subsystem, there's usually a tree you 
can go to to get just -linus plus the new subsystem.

> Also, fixups tend to have less needs for testing - and they're often
> backported to -bs.

"backported"?  So is -bs more stable than mainline?  I thought it was your 
development tree...

> Also, I don't tend to merge big patches without first checking.

Testing -mm (except for fun) doesn't work for me because too much other stuff 
is in there and if something breaks I don't know what it is.  (It's nice to 
test it and be able to give a thumbs up if it passes.  But failure in -mm is 
not always a useful data point.  Certainly not without "ok, -linus plus 
-uml-current worked, so something else in -mm is breaking UML on x86-64 
building under PLD..."

> > I'm not applying the other patches at the moment.  Right now I'm just
> > trying to get Jeff's tree to build for me.
>
> Which means applying your own fixups.

When absolutely necessary, yes.  In theory Jeff's tree works for Jeff so i'm 
trying to get it to work for me _without_ fixing it myself.  (Instead I bug 
_him_. :)  But I'm on a wildly different distro (ubuntu on x86 and PLD on 
x86-64) and things like maszur's headers or the /lib64 thing I haven't got 
much choice to patch myself.

I try not to _keep_ these patches.  You'll notice I post them here in hopes 
mainline fixes the problem (whether my fix or a different one).

> > If I have time tonight I'm
> > going to cherry-pick his patch list to see which ones I can get to
> > compile, and give him the list of each one that breaks my build (and
> > how).
>
> I suggest quilt exactly because it automates one big task - managing the
> stacks of applied and unapplied patches. Will "patch" suggest you which
> patch is the top one?

What I'm currently doing is:

for in in `cat patches/series`
do
  echo $i
  patch -p1 -i patches/$i
done

I.E. I'm letting Jeff's "series" indicate which order they should go in.

I have nothing against quilt but learning new tools tends to go on my todo 
list.  I go down enough tangential ratholes in an average day as it is. :)

> Quilt will. That's why I suggest you to try it. 

I'm trying very hard to _avoid_ managing my own tree, thanks.  If I ever have 
more than about three patches I'm applying to the tree at once, it's time to 
either push to get them in mainline or upgrade to a newer version.

With the linux kernel I'm applying squashfs (which I would very much like to 
see in mainline but I seem to have missed that flamewar this time 'round), 
and one three line removal.  The rest is fixups to 2.6.15-rc1 that I hope to 
see in -rc2 or -rc3.

For systems I do lots of new development on, I just use subversion.

> > I just
> > mentioned that #2 of the recent 4 sent to Andrew broke the build for me,
> > but that's not the only breakage I see from Jeff's tree.  (I currently
> > have access to four different build environments.  I was focusing on the
> > PLD x86-64 system I'm borrowing, but right now I'm focusing on my ubuntu
> > laptop.  Then knoppix, and then my Linux From Scratch system with gcc
> > 4.0.2 and uClibc...
> >
> > Expect to be hearing from me a lot. :)
>
> No problem... just be patient for fixes.

I know. :)

> And IMHO you shouldn't feel so shy  about fixing such compile problems (no
> complaining!) I don't expect you to debug the stub problems, but the rest
> should be easier to work with. 

I fixed the header #include problem myself once I understood that Jeff had 
never used Mazur's headers.  He took my patch for that.

The /lib64 thing I have no _clue_ how the linker stage of the linux kernel 
works (it has a linker script to tell ld what to do, and does black magic 
with elf segments so it can put stuff into the init segment and make a module 
export list and...  Ummm..  Eek.)  I know my patch there is wrong (it breaks 
x86), figuring out what to do about that is a todo item..

The recent breakage I saw with patches.tar was too much damage for Jeff _not_ 
to have seen, so it was either some kind of compiler version problem where my 
patches were likely to break _his_ system, or else I didn't understand what 
was going on.  (And #2 was the case: once I found out it was the 0 length 
files, I could fix that.  I didn't expect 0 length files screwing up the 
#include search paths.  The #include search paths are confusing, I'm still a 
bit fuzzy on the difference between include and include2, actually...)

I'm happy to debug stuff myself, when I can.  And to submit patches...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 17:52, Jeff Dike wrote:
> > > I tend to send directly to Andrew and he forwards them to Linus (in
> > > many cases so fast that I wonder if they appear in one -mm release),
> > > but I currently do not have a public tree.
>
> And you're welcome to send directly to Andrew, but feel free to send
> them to me beforehand.

Can I second the "send UML patches to Jeff and let him send them on to 
Andrew/Linus" approach?  Please?  It makes it much easier for me to test, 
with a known working system plus UML-only changes...

>     Jeff

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Jeff Dike]

On Fri, Nov 18, 2005 at 01:17:03AM -0600, Rob Landley wrote:
> > Definitely Jeff's tree is a first filter for his work, but I've not seen it
> > working a lot as a collector, especially for little fixes - but there it
> > makes sense.

I'd like it to be a collector of patches.  I just don't see a lot of them
(IIRC, the ones I do see are already on their way to akpm/linus, so it
makes not too much sense to exercise them in my tree).  Witness the OS
patches, the s390 stuff, and the NPTL patches (which I went and found
myself, which turned out to be a really good move).

> > I tend to send directly to Andrew and he forwards them to Linus (in many
> > cases so fast that I wonder if they appear in one -mm release), but I
> > currently do not have a public tree.

And you're welcome to send directly to Andrew, but feel free to send
them to me beforehand.


				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 18:55, Jeff Dike wrote:
> On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
> > Can I second the "send UML patches to Jeff and let him send them on to
> > Andrew/Linus" approach?  Please?  It makes it much easier for me to test,
> > with a known working system plus UML-only changes...
>
> I never firsted this.  In fact, I want BB to send stuff around me.  He
> has good judgement, and it saves me work.
>
> I'll happily add things to my tree (and I'll add the stuff he sends
> directly to akpm if it'll make things easier).

I just want one UML patch set I can apply against the most recent -linus to 
try out the new stuff.  How is entirely up to you guys. :)

Oh, speaking of which...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Jeff Dike]

On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
> Can I second the "send UML patches to Jeff and let him send them on to 
> Andrew/Linus" approach?  Please?  It makes it much easier for me to test, 
> with a known working system plus UML-only changes...

I never firsted this.  In fact, I want BB to send stuff around me.  He
has good judgement, and it saves me work.

I'll happily add things to my tree (and I'll add the stuff he sends
directly to akpm if it'll make things easier).

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Friday 18 November 2005 09:41, Rob Landley wrote:
> On Friday 18 November 2005 01:51, Blaisorblade wrote:
> > On Friday 18 November 2005 08:17, Rob Landley wrote:
> > > On Friday 18 November 2005 01:08, Blaisorblade wrote:
> > > > On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > > > > Linus said this:
> >
> > Btw, where does this quote come from?

Thanks for the pointers...

> The problem is (as the discussion brought up), Andrew's tree integrates
> many things.  If you want to test _just_ one subsystem, there's usually a
> tree you can go to to get just -linus plus the new subsystem.

> > Also, fixups tend to have less needs for testing - and they're often
> > backported to -bs.

> "backported"?  So is -bs more stable than mainline?  I thought it was your
> development tree...

No, it stands for "Blaisorblade stable". When you see a -bb release, _that_ is 
for development (in recent times, I used it only for skas0 backport).

Btw, there is even a FAQ on the site... ("Frequently" could be called a joke 
probably, but during first months people were clearly showing my site was 
impossible to understand).

> > Also, I don't tend to merge big patches without first checking.

> Testing -mm (except for fun) doesn't work for me because too much other
> stuff is in there and if something breaks I don't know what it is.

Same reason for which I don't use it :-(


> When absolutely necessary, yes.  In theory Jeff's tree works for Jeff so
> i'm trying to get it to work for me _without_ fixing it myself.  (Instead I
> bug _him_. :)  But I'm on a wildly different distro (ubuntu on x86 and PLD
> on x86-64) and things like maszur's headers or the /lib64 thing I haven't
> got much choice to patch myself.

Btw, why hasn't maszur went to post patches to kernel headers to make them 
includable from userspace instead of merging kernel changes into his headers 
(which is much more work)? Kernel headers, notwithstanding with what Linus 
can say, _do_ use __KERNEL__ and are not sanitized enough (PTRACE_SETOPTIONS 
from 2.6 headers produces a binary not working on 2.4 hosts - you must switch 
to OLDSETOPTIONS).

> I try not to _keep_ these patches.  You'll notice I post them here in hopes
> mainline fixes the problem (whether my fix or a different one).

Hmm... ok, we've different needs - had I done that I wouldn't have got my 
patches merged in many cases (partially because Jeff knows I have my tree and 
I can merge things myself - he merges my patches adaptively).

> > And IMHO you shouldn't feel so shy  about fixing such compile problems
> > (no complaining!) I don't expect you to debug the stub problems, but the
> > rest should be easier to work with.

> I fixed the header #include problem myself once I understood that Jeff had
> never used Mazur's headers.  He took my patch for that.

> The /lib64 thing I have no _clue_ how the linker stage of the linux kernel
> works (it has a linker script to tell ld what to do, and does black magic
> with elf segments so it can put stuff into the init segment and make a
> module export list and...  Ummm..  Eek.)  I know my patch there is wrong
> (it breaks x86), figuring out what to do about that is a todo item..

Ok, done in the other mail.

> The recent breakage I saw with patches.tar was too much damage for Jeff
> _not_ to have seen, so it was either some kind of compiler version problem
> where my patches were likely to break _his_ system, or else I didn't
> understand what was going on.  (And #2 was the case: once I found out it
> was the 0 length files, I could fix that.  I didn't expect 0 length files
> screwing up the #include search paths.

No, we have something like 

include/asm-um/elf.h: 
	ln -s elf-$(SUBARCH).h include/asm-um/elf.h

and make considers the target built when the file exists.

> The #include search paths are 
> confusing, I'm still a bit fuzzy on the difference between include and
> include2, actually...)
Just look at them on a built tree.... 

$ ls -l $OUT/include
total 6
lrwxrwxrwx    1 paolo paolo    6 18 nov 09:06 asm -> asm-um
drwxr-xr-x    2 paolo paolo  328 18 nov 09:06 asm-um
drwxr-xr-x  119 paolo paolo 5744 18 nov 09:06 config
drwxr-xr-x    2 paolo paolo  144 19 nov 03:13 linux

$ ls -l $OUT/include2
total 0
lrwxrwxrwx  1 paolo paolo 59 19 nov 03:13 asm 
-> /home/paolo/Admin/kernel/6/VCS/linux-2.6.git/include/asm-um

As you see, in include there are directories for generated files; Kbuild 
creates include2 to generate the normal asm symlink in it, pointing to the 
original asm-$(ARCH).

There is a distinction between the "asm" directory for normal headers and the 
"asm" directory for build-generated headers.

Ah, for all the rest -I$(srctree)/include is also used, but as you can't 
create $(srctree)/include/asm, <asm/header.h> will not be found on it, even 
if header.h is not build-generated.

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 20:33, Blaisorblade wrote:
> > When absolutely necessary, yes.  In theory Jeff's tree works for Jeff so
> > i'm trying to get it to work for me _without_ fixing it myself.  (Instead
> > I bug _him_. :)  But I'm on a wildly different distro (ubuntu on x86 and
> > PLD on x86-64) and things like maszur's headers or the /lib64 thing I
> > haven't got much choice to patch myself.
>
> Btw, why hasn't maszur went to post patches to kernel headers to make them
> includable from userspace instead of merging kernel changes into his
> headers (which is much more work)?

For the same reason the glibc guys don't ship a patch against the kernel 
headers but ship cleaned upkernel headers.  It's much smaller and simpler, 
and the patch would break with every single release.  Besides, the patch 
isn't what we need to build libc, the cleaned up headers are.  It would add 
an unnecessary level of indirection and _never_ get merged into the main 
kernel?

Did I say never?  Yes, I did.  I take it you missed the periodic flamewars on 
this issue?  The kernel guys _actively_ don't care about userspace headers:
http://seclists.org/lists/linux-kernel/2003/Aug/5229.html

You read that right: stable userspace includable kernel headers were bumped to 
2.7, which ain't happening.  That was 2003.  Here's Linus Torvalds in 2004 
shooting down the next stab at it:
http://lwn.net/Articles/113349/

And my salvo in that discussion:
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.0/0866.html

Mazur participated in this and got his head handed to him by Linus Torvalds.  
Random example of the exchange here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/1708.html

The kernel developers will sort of agree in theory that userspace needs to 
somehow know about the kernel API, but every single specific proposal ever 
brought up to clean up the kernel headers so userspace can more easily 
include them _always_ gets shot down because this work is not necessary to 
compile the linux kernel itself, and is therefore unnecessary churn from 
kernel developers' point of view.  (Userspace be damned.)

> Kernel headers, notwithstanding with 
> what Linus can say, _do_ use __KERNEL__ and are not sanitized enough
> (PTRACE_SETOPTIONS from 2.6 headers produces a binary not working on 2.4
> hosts - you must switch to OLDSETOPTIONS).

A periodic feature of the recurring flamewar is the proposal to remove all 
#ifdef __KERNEL__ notations from the kernel headers.  Here's an example from 
2001...

http://www.ussg.iu.edu/hypermail/linux/kernel/0107.2/0480.html

How serious they are about it varies from year to year...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Henrik Nordstrom]

On Fri, 18 Nov 2005, Rob Landley wrote:

> was going on.  (And #2 was the case: once I found out it was the 0 length
> files, I could fix that.  I didn't expect 0 length files screwing up the
> #include search paths.  The #include search paths are confusing, I'm still a
> bit fuzzy on the difference between include and include2, actually...)

0-length files after patching is generally due to slightly incorrectly 
formatted patches, and can screw up a lot of things.

From the patch man page:

   you can remove a file by sending out a context diff that compares
   the file to be deleted with an empty file dated the Epoch.  The
   file will be removed unless patch is conforming to POSIX and the
   -E or --remove-empty-files option is not given.

A few other formats also works, but what is said above is the safest patch 
format for removal of files.

If you find patches which removes files using a format not complying with 
the above then it may be wise to ask the person who published the patch to 
change his routines to make correctly formatted patches. On the sad side 
there is a number of widespread tools not generating such patches 
correctly (CVS is one.. have a cleanpatch script at devel.squid-cache.org 
fixing this and a few other CVS diff -u stupidities)

Regarding the include path, Compliers, make etc just searches their paths 
until a file is found, no attempt in verifying the validity of the file is 
made. If the found file is empty then in the input at that stage is 
empty, and if the actual file which was supposed to be found is in a later 
element in the search path then you get screwed.

Regards
Henrik


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Sunday 20 November 2005 00:40, Henrik Nordstrom wrote:
> On Fri, 18 Nov 2005, Rob Landley wrote:
> > was going on.  (And #2 was the case: once I found out it was the 0 length
> > files, I could fix that.  I didn't expect 0 length files screwing up the
> > #include search paths.  The #include search paths are confusing, I'm
> > still a bit fuzzy on the difference between include and include2,
> > actually...)

> 0-length files after patching is generally due to slightly incorrectly
> formatted patches, and can screw up a lot of things.

> From the patch man page:

>    you can remove a file by sending out a context diff that compares
>    the file to be deleted with an empty file dated the Epoch.  The
>    file will be removed unless patch is conforming to POSIX and the
>    -E or --remove-empty-files option is not given.

> A few other formats also works, but what is said above is the safest patch
> format for removal of files.

> If you find patches which removes files using a format not complying with
> the above then it may be wise to ask the person who published the patch to
> change his routines to make correctly formatted patches. On the sad side
> there is a number of widespread tools not generating such patches
> correctly (CVS is one.. have a cleanpatch script at devel.squid-cache.org
> fixing this and a few other CVS diff -u stupidities)

Hmm, quilt, git (and IIRC BitKeeper) don't comply with the above format, but 
they use /dev/null and it seems to work in practice. Jeff's version of quilt 
seems to be broken on this (he said he's using 0.32).

> Regarding the include path, Compliers, make etc just searches their paths
> until a file is found, no attempt in verifying the validity of the file is
> made. If the found file is empty then in the input at that stage is
> empty, and if the actual file which was supposed to be found is in a later
> element in the search path then you get screwed.

This case is a little different as I already explained...

In this case the 0-lenght file, when missing, would trigger make "building 
it" (i.e. creating it as a symlink with correct content).


-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Monday 21 November 2005 04:25, Nix wrote:
> On Fri, 18 Nov 2005, Rob Landley wrote:
> > On Friday 18 November 2005 20:33, Blaisorblade wrote:
> >> Btw, why hasn't maszur went to post patches to kernel headers to make
> >> them includable from userspace instead of merging kernel changes into
> >> his headers (which is much more work)?
> >
> > For the same reason the glibc guys don't ship a patch against the kernel
> > headers but ship cleaned upkernel headers.  It's much smaller and
> > simpler, and the patch would break with every single release.  Besides,
> > the patch isn't what we need to build libc, the cleaned up headers are. 
> > It would add an unnecessary level of indirection and _never_ get merged
> > into the main kernel?
>
> One problem is that Mariusz's linux-libc-headers work seems to have
> stalled :( the last headers out there are for 2.6.12, and increasingly much
> (e.g. iptables) needs to be pointed directly at the kernel headers again.
>
> I hope linux-libc-headers isn't dead. It looked like it was turning into
> a very good aggregation point, with patches coming in from Ubuntu and RH
> among others.

Hopefully he won't mind me quoting from his email on Nov 4th.  Project's not 
dead, he's just busy with Real Life (tm):

> I'm also CCing Wojtek Cieciwa (cieciwa@pld-linux.org), since he's one of the 
> guys that need a new llh release and I should be releasing 2.6.14.0 right 
> about now (my world kind of collapsed a few days ago and I'm out of the 
> picture for don't know how long; I hope to be able to recover within a week, 
> but who nows how things will work out; keep me CCed though).

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Nix]

On Mon, 21 Nov 2005, Rob Landley wrote:
> On Monday 21 November 2005 04:25, Nix wrote:
>> I hope linux-libc-headers isn't dead. It looked like it was turning into
>> a very good aggregation point, with patches coming in from Ubuntu and RH
>> among others.
> 
> Hopefully he won't mind me quoting from his email on Nov 4th.  Project's not 
> dead, he's just busy with Real Life (tm):

It sounds worse than `busy' to me.

>> I'm also CCing Wojtek Cieciwa (cieciwa@pld-linux.org), since he's one of the 
>> guys that need a new llh release and I should be releasing 2.6.14.0 right 

Murphy's Law says it'll come out in one day's time or something (I've
just finished rebuilding glibc-2.3.6, you see ;) ).

>> about now (my world kind of collapsed a few days ago

Mariusz, I hope things have improved and your world is a-building anew.

-- 
`Y'know, London's nice at this time of year. If you like your cities
 freezing cold and full of surly gits.' --- David Damerell



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: merge status

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

>>>>> "Jeff" == Jeff Dike <jdike@addtoit.com> writes:
    Jeff> On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
    >> Can I second the "send UML patches to Jeff and let him send them on to
    >> Andrew/Linus" approach?  Please?  It makes it much easier for me to
    >> test, with a known working system plus UML-only changes...

    Jeff> I never firsted this.  In fact, I want BB to send stuff around me.
    Jeff> He has good judgement, and it saves me work.

  So, BB should collect patches .... will you publish a git tree?

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[-- Attachment #2: Type: application/pgp-signature, Size: 480 bytes --]

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Wednesday 30 November 2005 18:23, Michael Richardson wrote:
> >>>>> "Jeff" == Jeff Dike <jdike@addtoit.com> writes:
>
>     Jeff> On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
>     >> Can I second the "send UML patches to Jeff and let him send them on
>     >> to Andrew/Linus" approach?  Please?  It makes it much easier for me
>     >> to test, with a known working system plus UML-only changes...
>
>     Jeff> I never firsted this.  In fact, I want BB to send stuff around
> me. Jeff> He has good judgement, and it saves me work.

>   So, BB should collect patches .... will you publish a git tree?

For now not - I've not the time to do this... also I work more in a quilt like 
style (I use quilt and StGit).

There are means to make a quilt-like tree (managed with StGit) exportable, but 
I've never coded them up (and their semantic is difficult to get right).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel