[uml-devel] [POLL] Putting UML/2.4 into "fixes-only" mode

[uml-devel] [POLL] Putting UML/2.4 into "fixes-only" mode

[Blaisorblade]

Jeff, I've seen the beginning of your work on back-porting all the patches 
from 2.6 to 2.4...

It's a huge work, but what is more important, it could obviously hurt 
stability...

So, I'd suggest to follow this policy to choose the work to merge:

- reduce *a lot* what is going to be merged... no new features, no code 
cleanups (especially NOT the Makefiles cleanups)...

- concentrate on stability... and on backing out the hostfs rewrite.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
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: [uml-user] [POLL] Putting UML/2.4 into "fixes-only" mode

[Peter]

+1

For my purposes I need solid, stable code.  I prefer a a 2.4 and 2.6 
kernel that builds without too many config gotchas.  And runs reliably. 
  e.g. right now I am using the blaisorblade 2.6.9-bs patches and the 
pre-hostfs 2.4 code.  That works well.

I'm all for different UML trees/patches that try out new features and 
make major changes.  And I will contribute to testing those if needed. 
But I would like to keep those patches/trees separate from the 'stable' one.

It is your time, and you can spend it how you like (obviously).  I'd be 
most happy if new work went into the 2.6 tree if that meant more would 
be done.  That seems to be where all new distros are going (not 2.4). 
And (give or take a bug or two) most of my UML instances run really well 
on the 2.6 tree.  If I had a really solid 2.6 kernel I don't think I'd 
even need the 2.4 one.

So if you can save some backporting efforts, work on adding more 2.6 
stability and new features (on the separate -mm type tree) that could be 
a win-win.

Cheers, Peter



Blaisorblade wrote:
> Jeff, I've seen the beginning of your work on back-porting all the patches 
> from 2.6 to 2.4...
> 
> It's a huge work, but what is more important, it could obviously hurt 
> stability...
> 
> So, I'd suggest to follow this policy to choose the work to merge:
> 
> - reduce *a lot* what is going to be merged... no new features, no code 
> cleanups (especially NOT the Makefiles cleanups)...
> 
> - concentrate on stability... and on backing out the hostfs rewrite.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
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: [uml-user] [POLL] Putting UML/2.4 into "fixes-only" mode

[D. Bahi]

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

I would like a 2.4 that is stable. with a working hostfs.
(that i can run valgrind against - heh, not umls fault here.)
Also, the uml web site needs to be authoritative. building
the above should not require patching from additional
sources announced on the list.

That said, 2.4 and 2.6 are both 'stable' kernel branches
that have had quite a bit of UML development in them. So,
if it helps future maintaining of both 2.4 and 2.6, at
least until 2.7 appears, then do what you need to do.
please don't abandon 2.4 until 2.7 is well under way.

Maybe you could break up the 2.4 patches into 'stable'
'testing' and 'experimental' ?

db

Blaisorblade wrote:

>Jeff, I've seen the beginning of your work on back-porting all the patches 
>from 2.6 to 2.4...
>
>It's a huge work, but what is more important, it could obviously hurt 
>stability...
>
>So, I'd suggest to follow this policy to choose the work to merge:
>
>- reduce *a lot* what is going to be merged... no new features, no code 
>cleanups (especially NOT the Makefiles cleanups)...
>
>- concentrate on stability... and on backing out the hostfs rewrite.
>  
>

-- 
db


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [uml-devel] Re: [uml-user] [POLL] Putting UML/2.4 into "fixes-only" mode

[Blaisorblade]

On Thursday 27 January 2005 03:22, D. Bahi wrote:
> I would like a 2.4 that is stable. with a working hostfs.
Tried 2.4.27-bs1?
> (that i can run valgrind against - heh, not umls fault here.)
I've never seen valgrind actually working against UML - Jeff Dike did some 
work on Valgrind on this area time ago, but it wasn't merged and the Valgrind 
author said that Valgrind does not at all supports program using the "clone" 
call. And UML is one heavy user of this call.

> Also, the uml web site needs to be authoritative. building
> the above should not require patching from additional
> sources announced on the list.

> That said, 2.4 and 2.6 are both 'stable' kernel branches
> that have had quite a bit of UML development in them. So,
> if it helps future maintaining of both 2.4 and 2.6, at
> least until 2.7 appears, then do what you need to do.
> please don't abandon 2.4 until 2.7 is well under way.
This does not work... nobody knows if 2.7 will ever start *at all* (really).
> Maybe you could break up the 2.4 patches into 'stable'
> 'testing' and 'experimental' ?
Time is limited - managing two trees (in this case, two 2.4 trees) and porting 
patches back and forth between them is a hard, difficult, error-prone work.

However, I've not claimed "abandoning" the 2.4 tree.

However, who uses the 2.4 tree wants stability over everything else (in most 
cases), otherwise would use the 2.6 tree.

So, actually, we cannot debug invasive patches on 2.4: you need lots of users 
testing and reporting about them and helping to narrow down possible bugs.

So, for instance, it would be useless to backport the /proc/sysemu feature 
(which was a bit tricky to get right on 2.6 already, especially because 
uncovered some bugs in the SYSEMU host patch).

> Blaisorblade wrote:
> >Jeff, I've seen the beginning of your work on back-porting all the patches
> >from 2.6 to 2.4...

> >It's a huge work, but what is more important, it could obviously hurt
> >stability...

> >So, I'd suggest to follow this policy to choose the work to merge:

> >- reduce *a lot* what is going to be merged... no new features, no code
> >cleanups (especially NOT the Makefiles cleanups)...

> >- concentrate on stability... and on backing out the hostfs rewrite.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
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: [POLL] Putting UML/2.4 into "fixes-only" mode

[Jeff Dike]

blaisorblade@yahoo.it said:
> It's a huge work, but what is more important, it could obviously hurt
> stability...

Yes.

> So, I'd suggest to follow this policy to choose the work to merge:
>
> - reduce *a lot* what is going to be merged... no new features, no
> code  cleanups (especially NOT the Makefiles cleanups)...
>
> - concentrate on stability... and on backing out the hostfs rewrite. 

This makes all kinds of sense.  But, from my point of view, if I'm going 
maintain both 2.4 and 2.6 trees, I want them to be as similar as possible.

We can go through the patches, and I got a nice list of them, and I was 
planning on going through them and applying all of the ones that made sense
in 2.4.

So, your proposal makes sense from the point of a large number of users,
but you're signing me up for a whole lot of extra work.  So, I'm not too
inclined to run a stability 2.4 tree, as much sense as it makes.  

Are you?  Or someone else?  I've got this nice list of patches, and I'll
be happy to go through them and categorize them in terms of their effects
on stability.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
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] [POLL] Putting UML/2.4 into "fixes-only" mode

[Henrik Nordstrom]

On Wed, 26 Jan 2005, Blaisorblade wrote:

> So, I'd suggest to follow this policy to choose the work to merge:
>
> - reduce *a lot* what is going to be merged... no new features, no code
> cleanups (especially NOT the Makefiles cleanups)...
>
> - concentrate on stability... and on backing out the hostfs rewrite.

I am all for this. People wanting "new fetures" should be using the 2.6 
tree + relevant patches anyway. 2.4 should focus only on stability, 
nothing else.

If there is users willing to have new features in 2.4 to the point that 
they provide these features backported to 2.4 then I am OK with having an 
"experimental" 2.4 patch with these aplied, but I do not think these 
belongs in the main 2.4 patch.

Regards
Henrik


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
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: [POLL] Putting UML/2.4 into "fixes-only" mode

[Blaisorblade]

On Saturday 29 January 2005 06:39, you wrote:
> blaisorblade@yahoo.it said:
> > It's a huge work, but what is more important, it could obviously hurt
> > stability...

> Yes.

> > So, I'd suggest to follow this policy to choose the work to merge:
> >
> > - reduce *a lot* what is going to be merged... no new features, no
> > code  cleanups (especially NOT the Makefiles cleanups)...
> >
> > - concentrate on stability... and on backing out the hostfs rewrite.

> This makes all kinds of sense.  But, from my point of view, if I'm going
> maintain both 2.4 and 2.6 trees, I want them to be as similar as possible.

> We can go through the patches, and I got a nice list of them, and I was
> planning on going through them and applying all of the ones that made sense
> in 2.4.

> So, your proposal makes sense from the point of a large number of users,
> but you're signing me up for a whole lot of extra work.  So, I'm not too
> inclined to run a stability 2.4 tree, as much sense as it makes.

> Are you?  Or someone else?  I've got this nice list of patches, and I'll
> be happy to go through them and categorize them in terms of their effects
> on stability.

Well, there are two things that you can do to *avoid* increasing your work:

- avoid backporting cleanups, like the bh one... it's just lost time.

- avoid if possible to backport new features...

- concentrate on the recent security fixes, if possible... the 
syscall-security-1/6 fixes were not enough on 2.6 to fix everything, so for 
me it's evident they cannot suffice on 2.4.

Also, it's not the kind of work which is easy to delegate (to me at least) - 
those patches hack the UML core and I've not followed them well - for missing 
time and for their difficulty.

Also, now, I'm doing some more work on the 2.4 tree - I've some fixes I found 
useful, like the 2.6.4 scheduler fixes which weren't merged in 2.4 and some 
more recent ones.

I did that to try fixing the /dev/urandom bug, before realizing that the 
problem is in some code related to the urandom driver... the reported panic 
is just a "scheduling in interrupt" one. It means also that the problem is 
due probably to something in UML that is used by the driver. Suggestions:

- timing code
- interrupt code (they are entropy sources).

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel