Andrew, what are the requisite for stable inclusion of the UML update inside
2.6-mm (or directly 2.6.8)? Currently (splitting out a little piece, which
should not be included) we have almost all the stuff inside arch/um and
include/asm-um, the addition of <linux/ghash.h> and of two filesystems for
UML use only, and this little hunk (plus 2 uses of it inside
mm/page_alloc.c).
+#ifndef HAVE_ARCH_FREE_PAGE
+static inline void arch_free_page(struct page *page, int order) { }
+#endif
Could it go in as-is? I'm especially worried about having it included soon in
2.6.8, since last time it entered -mm and stayed there just for one release.
The patch correctly applies to 2.6.7 and works; the current code, instead,
does not even compile at all, so there is no reason for not applying it
(unless you want to remove UML support / but since you never said this, we
need this patch applied). However, if you don't want some parts of the code,
just tell me; I'm waiting for this before preparing the UML patch to send you
Also, I have some patches managed with your patch-scripts, which I'll send you
after you include the UML patch.
About the STATE of the code:
Of the two filesystems, one (hostfs) now should work perfectly with 2.6 (I've
just fixed one porting bug to 2.6, related to the force_delete() ->
.drop_inode change documented in Documentation/filesystems/vfs.txt); the
other maybe has some problems, but I can remove it from the patch (it also
will probably be replaced soon by a more generic one, i.e. externfs).
Bye!
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
On Sat, Jun 26, 2004 at 07:05:22PM +0200, BlaisorBlade wrote:
> Andrew, what are the requisite for stable inclusion of the UML update inside
> 2.6-mm (or directly 2.6.8)? Currently (splitting out a little piece, which
> should not be included) we have almost all the stuff inside arch/um and
> include/asm-um, the addition of <linux/ghash.h> and of two filesystems for
> UML use only, and this little hunk (plus 2 uses of it inside
> mm/page_alloc.c).
>
> +#ifndef HAVE_ARCH_FREE_PAGE
> +static inline void arch_free_page(struct page *page, int order) { }
> +#endif
>
> Could it go in as-is? I'm especially worried about having it included soon in
> 2.6.8, since last time it entered -mm and stayed there just for one release.
Please send split patches. E.g. linux/ghash.h should not ne reintroduced,
it's completely fuly. Also your above arch_free_page needs some more
discussion.
BlaisorBlade <[email protected]> wrote:
>
> Andrew, what are the requisite for stable inclusion of the UML update inside
> 2.6-mm
I have no problem plopping it into -mm, as long as it doesn't cause me too
much pain. It did cause patch management pain last time, but probably
whatever is was interacting with has now been merged up so it'll be OK.
But for a merge into mainline we do need to get down and do some work on it
- reintroducing ghash.h would not be welcome (I though Jeff was going to
eliminate that?) and last time we looked the patch had some blockdev
drivers in it which were doing antiquated 2.4 things.
Generally, UML in 2.6 seems to have fallen behind fairly seriously and at
some stage we need to go through the exercise of splitting the patch up,
reviewing and fixing all the bits and feeding it in.
On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
> Please send split patches. E.g. linux/ghash.h should not ne reintroduced,
> it's completely fuly.
That requires a little interface work inside UML, and that was the main reason
Andrew hasn't seen UML recently.
> Also your above arch_free_page needs some more
> discussion.
I think that can disappear. In some cases, it might be handy for the arch
to see pages being freed, but right now, I believe that UML has no need for
it.
Jeff
On Sat, Jun 26, 2004 at 01:09:45PM -0700, Andrew Morton wrote:
> I have no problem plopping it into -mm, as long as it doesn't cause me too
> much pain. It did cause patch management pain last time, but probably
> whatever is was interacting with has now been merged up so it'll be OK.
The tty_init patch is gone, so ghash is the only nasty bit outside the arch
tree.
> But for a merge into mainline we do need to get down and do some work on it
> - reintroducing ghash.h would not be welcome (I though Jeff was going to
> eliminate that?)
Yeah, it will be, but requires a bit of surgery.
> and last time we looked the patch had some blockdev
> drivers in it which were doing antiquated 2.4 things.
Not sure about that. hch complained about the cow driver last time, which
can disappear until there is something that vaguely works.
>
> Generally, UML in 2.6 seems to have fallen behind fairly seriously and at
> some stage we need to go through the exercise of splitting the patch up,
> reviewing and fixing all the bits and feeding it in.
Yup. I've come to the conclusion that I've painted myself into a corner a
bit with BK and my currently style of working. I'm looking at quilt, and
I'm pondering taking all the changes since the last time Linus merged UML
(2.5.69 or something), and breaking them up into sensible patches.
That'll be a lot of work, but I think it's something that needs doing.
Jeff
> I'm looking at quilt
Good tool.
It's a bit like a loaded gun with no safety. You will learn a few new
ways to shoot your foot off, and become good at first aid. You will
want someway to keep personal revision history of your patches, to aid
in such repair work. CVS or RCS or local bitkeeper or (for ancient
hackers like me) raw SCCS or some such. Quilt handles the patches, but
in and of itself has nothing to do with preserving history.
All software is divided into two parts - the concrete and the fluid.
Once something is accepted into the main kernel, it's concrete. You can
never go back - you can only layer fixes on top. Bitkeeper rules for
this stuff.
But work in progress, for which oneself is still the primary source, is
fluid. You can slice and dice and redo it, and indeed you want to, to
get the best patch set. Quilt and friends rule for this stuff.
Conclusion - use Quilt (with your favorite personal version control) on
top of Bitkeeper.
Question - what tools are available for convenient patch set submission?
Composing multiple, related email sets in a GUI emailer is a bit tedious
and error prone. It's an obvious candidate for scripting.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
Paul Jackson <[email protected]> wrote:
>
> > I'm looking at quilt
>
> Good tool.
>
> It's a bit like a loaded gun with no safety. You will learn a few new
> ways to shoot your foot off, and become good at first aid. You will
> want someway to keep personal revision history of your patches, to aid
> in such repair work. CVS or RCS or local bitkeeper or (for ancient
> hackers like me) raw SCCS or some such. Quilt handles the patches, but
> in and of itself has nothing to do with preserving history.
>
> All software is divided into two parts - the concrete and the fluid.
>
> Once something is accepted into the main kernel, it's concrete. You can
> never go back - you can only layer fixes on top. Bitkeeper rules for
> this stuff.
>
> But work in progress, for which oneself is still the primary source, is
> fluid. You can slice and dice and redo it, and indeed you want to, to
> get the best patch set. Quilt and friends rule for this stuff.
Good description, that. quilt is a grown-up version of patch-scripts, and
is tailored to what I do, and to what distributors do: maintain a series of
diffs against a monolithic tree which someone else maintains.
> Conclusion - use Quilt (with your favorite personal version control) on
> top of Bitkeeper.
yup. I use patch-scripts+CVS in the way which you describe.
> Question - what tools are available for convenient patch set submission?
> Composing multiple, related email sets in a GUI emailer is a bit tedious
> and error prone. It's an obvious candidate for scripting.
patch-scripts has the "patch-bomb" script, which would presumably work OK
for quilt - it would need a little tweaking.
http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.18/
> patch-scripts has the "patch-bomb" script,
Aha - interesting.
Actually, I was asking a loaded question. I just finished writing my
own patch bomber. I see a few details in your patch-bomb worth stealing
- thanks. Mine is more driven off of a single text file, that specifies
what files, with what subjects, to send to whom. And its in Python.
The big feature (?) mine has is to set the Message-Id, In-Reply-To and
References fields so that all but the first one in the set appear to be
followups to the first one, for those using threaded email readers.
Hard to do that with smtpsend in the shell ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
On Sat, 26 Jun 2004, Paul Jackson wrote:
> Question - what tools are available for convenient patch set submission?
> Composing multiple, related email sets in a GUI emailer is a bit tedious
> and error prone. It's an obvious candidate for scripting.
The scripts I use to keep m68k up-to-date are available at:
http://linux-m68k-cvs.apia.dhs.org/~geert/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sun, 2004-06-27 at 08:40, Andrew Morton wrote:
> Paul Jackson <[email protected]> wrote:
> >
> > > I'm looking at quilt
> >
> > Good tool.
> >
> > It's a bit like a loaded gun with no safety. You will learn a few new
> > ways to shoot your foot off, and become good at first aid.
Ideas for improvement are always welcome -- they would best be discussed
on http://lists.nongnu.org/mailman/listinfo/quilt-dev.
> > You will
> > want someway to keep personal revision history of your patches, to aid
> > in such repair work. CVS or RCS or local bitkeeper or (for ancient
> > hackers like me) raw SCCS or some such. Quilt handles the patches, but
> > in and of itself has nothing to do with preserving history.
> >
> > All software is divided into two parts - the concrete and the fluid.
> >
> > Once something is accepted into the main kernel, it's concrete. You can
> > never go back - you can only layer fixes on top. Bitkeeper rules for
> > this stuff.
> >
> > But work in progress, for which oneself is still the primary source, is
> > fluid. You can slice and dice and redo it, and indeed you want to, to
> > get the best patch set. Quilt and friends rule for this stuff.
>
> Good description, that. quilt is a grown-up version of patch-scripts, and
> is tailored to what I do, and to what distributors do: maintain a series of
> diffs against a monolithic tree which someone else maintains.
The concepts behind quilt are all stolen from patch-scripts, so it has
the same usability problem that patch-scripts has: forgetting to add a
file to a patch before modifying it is painful. the ``quilt edit''
command helps somewhat. I do not have a good idea how to fix this in a
more satisfactory way.
Quilt is missing some of the features of patch-scripts: there are no
equivalents to export_patch, which renames exported patches so that the
filename sort order equals the order of the patches in the series file.
Neither is there a way to strip such sequencing prefixes when importing
patches. (I consider this obsolete.) There is nothing kernel specific,
and nothing specific to version control systems. Also there are no
equiovalents to patch-scripts's new-kernel, mv-patch, patch-bomb,
pstatus, rename-patch, tag-series, unitdiff.py commands.
On the other hand there are lots of small improvements, no more patch
control files (that list the files a patch touches in patch-scripts),
improved diffing and status inquiry functionality, patch dependency
analysis, support for RPM packages. And there is more documentation.
Things I'm currently considering include:
- handling of meta-information such as one-line summary, author,
description,
- support for diffstat (re-add; we had this in older versions),
- a patch-bomb equivalent.
All of the above things will potentially conflict with the goal of
keeping the whole thing as policy-free and generally useful as possible.
> > Conclusion - use Quilt (with your favorite personal version control) on
> > top of Bitkeeper.
>
> yup. I use patch-scripts+CVS in the way which you describe.
Same here.
Cheers,
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX AG
On Sat, 26 Jun 2004, Jeff Dike wrote:
> On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
> > Also your above arch_free_page needs some more discussion.
>
> I think that can disappear. In some cases, it might be handy for the
> arch to see pages being freed, but right now, I believe that UML has no
> need for it.
Should be useful for Linux/Xen, Linux/s390 and Linux/iSeries,
too...
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
> forgetting to add a file to a patch before modifying it is painful.
Yup.
One can dig ones way out by (1) copying the new code aside, (2)
unwinding until you can forcibly pop (or bk co) the pristine source
back, (3) push'ing back to the desired patch, (4) 'q edit' and copy over
the new code. But this is a "learned" response.
> I do not have a good idea how to fix this in a more satisfactory way.
Me neither.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
On Sonntag, 27. Juni 2004 15:57, Rik van Riel wrote:
> On Sat, 26 Jun 2004, Jeff Dike wrote:
> > On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
>
> > > Also your above arch_free_page needs some more discussion.
> >
> > I think that can disappear. ?In some cases, it might be handy for the
> > arch to see pages being freed, but right now, I believe that UML has no
> > need for it.
>
> Should be useful for Linux/Xen, Linux/s390 and Linux/iSeries,
> too...
At least for Linux/s390, the underlying architecture interface (DIAG 0x10)
that would let us exploit this is too expensive, so we chose not to do it.
Future machine might give us more flexibility, but using those requires
more than just hooking into free_page.
Arnd <><
On Sat, Jun 26, 2004 at 11:40:25PM -0700, Andrew Morton wrote:
>
> > But work in progress, for which oneself is still the primary source, is
> > fluid. You can slice and dice and redo it, and indeed you want to, to
> > get the best patch set. Quilt and friends rule for this stuff.
>
> Good description, that. quilt is a grown-up version of patch-scripts, and
> is tailored to what I do, and to what distributors do: maintain a series of
> diffs against a monolithic tree which someone else maintains.
>
> > Conclusion - use Quilt (with your favorite personal version control) on
> > top of Bitkeeper.
>
> yup. I use patch-scripts+CVS in the way which you describe.
I had been wondering how you deal with so many patches...
So do people actually use bitKeeper for more than the following:
(1) glorified 'cp -r'
(2) memory of the history of the tree from which we did a 'cp -r'
-dte
Alle 05:53, domenica 27 giugno 2004, Jeff Dike ha scritto:
> On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
> > Please send split patches. E.g. linux/ghash.h should not ne
> > reintroduced, it's completely fuly.
Anyway, I'm going to upload the whole patchset (as it is now); I just tarred
my ./patch-scripts folder, containing descriptions, .pc files and actual
patches. The updates from Jeff Dike are not very split, but everything I've
added is in his own separate patch. Little changes anyway.
I've problems with patch-bomb, so for now here is it:
http://www.user-mode-linux.org/~blaisorblade/patches/bb/uml-patch-2.6.7-01-bb2.tar.bz2
The description of things is below (and in the patches headings, mostly).
Also, my main fear is about 2.7: if it is split before UML is merged, it means
it won't be updated for all the API changes in 2.7.x.
For who want to flame with "better leave it broken than just doing compile
fixes": who introduced set_page_count, for instance, grepped and changed it
everywhere, even in the UML tree. And there was no reason to do so; so it
would help us having UML in mainline, to react well to such updates.
> That requires a little interface work inside UML, and that was the main
> reason Andrew hasn't seen UML recently.
>
> > Also your above arch_free_page needs some more
> > discussion.
>
> I think that can disappear. In some cases, it might be handy for the arch
> to see pages being freed, but right now, I believe that UML has no need for
> it.
Hmm, well, indeed that part was added just to support ubd-mmap, which you seem
to have decided to drop*, but removing it would be hard for me, since it
would mean doing a lot of checks to physmem handling; and I still don't want
to fight against all the bugs I'd create. I'm seeing a lot more ones simply
after switching to Mandrake 10 (don't flame me for this!) for my host.
The same thing holds for COW support: I cannot drop it so simply, since there
are some references to it in working UBD code. That code should just drop
them, since IIRC Jeff wants to make COW act on any two block devices; but
I've not time to do it.
I could, instead, safely remove the /proc/mm support (for running nested UMLs
in SKAS mode); the patch for this was well tested, so it's included; I'm
providing a "combinediffed" version of them, since without removing SKAS the
patch will probably not apply. I've also split ghash.h out.
* But when you say "It's vulnerable to the filesystem making changes to data
that it intends never to reach the disk" in your diary, you speak about a
performance problem, right? Or it is even broken?
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729