On Saturday 29 January 2005 06:39, you wrote:
> blaisorblade@... said:
> > 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 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