On Saturday 29 January 2005 06:39, you wrote: > [EMAIL PROTECTED] 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-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
