Hi,
I have updated dontdiff in the usual place:
http://www.moses.uklinux.net/patches/dontdiff
for the 2.6 kernels. Obviously this was only tested on my configuration(s)
so any additions are welcome. Just email them to me and I will add them.
For those who don't know what "dontdiff" is --- grep the file:
/usr/src/linux/Documentation/SubmittingPatches
Regards
Tigran
On Mon, Sep 01, 2003 at 07:57:27AM -0700, Tigran Aivazian wrote:
> Hi,
>
> I have updated dontdiff in the usual place:
>
> http://www.moses.uklinux.net/patches/dontdiff
>
> for the 2.6 kernels. Obviously this was only tested on my configuration(s)
> so any additions are welcome. Just email them to me and I will add them.
>
> For those who don't know what "dontdiff" is --- grep the file:
>
> /usr/src/linux/Documentation/SubmittingPatches
Btw, what about putting this somewhere in the kernel tree?
> On Mon, Sep 01, 2003 at 07:57:27AM -0700, Tigran Aivazian wrote:
> > I have updated dontdiff in the usual place:
> >
> > http://www.moses.uklinux.net/patches/dontdiff
> >
> > for the 2.6 kernels. Obviously this was only tested on my configuration(s)
> > so any additions are welcome. Just email them to me and I will add them.
> >
> > For those who don't know what "dontdiff" is --- grep the file:
> >
> > /usr/src/linux/Documentation/SubmittingPatches
>
> Btw, what about putting this somewhere in the kernel tree?
Probably a good idea, because I hesitated whether to call this
"dontdiff-2.6" and leave the existing dontdiff for 2.4 or just switch to
2.6 (assuming it is applicable to 2.4 as well). But if it is in the kernel
tree then no need to worry about which dontdiff matches which kernel.
Regards
Tigran
> Btw, what about putting this somewhere in the kernel tree?
and adding dontdiff file to the dontdiff file :)
On Mon, 1 Sep 2003, Maciej Soltysiak wrote:
> > Btw, what about putting this somewhere in the kernel tree?
> and adding dontdiff file to the dontdiff file :)
No, because it is not generated, so it shouldn't be in the dontdiff file :)
Tigran Aivazian wrote:
>>On Mon, Sep 01, 2003 at 07:57:27AM -0700, Tigran Aivazian wrote:
>>
>>>I have updated dontdiff in the usual place:
>>>
>>> http://www.moses.uklinux.net/patches/dontdiff
>>>
>>>for the 2.6 kernels. Obviously this was only tested on my configuration(s)
>>>so any additions are welcome. Just email them to me and I will add them.
>>>
>>>For those who don't know what "dontdiff" is --- grep the file:
>>>
>>>/usr/src/linux/Documentation/SubmittingPatches
>>
>>Btw, what about putting this somewhere in the kernel tree?
>
>
> Probably a good idea, because I hesitated whether to call this
> "dontdiff-2.6" and leave the existing dontdiff for 2.4 or just switch to
> 2.6 (assuming it is applicable to 2.4 as well). But if it is in the kernel
> tree then no need to worry about which dontdiff matches which kernel.
I'll throw it into 2.6. I use dontdiff all the time :)
FWIW I use the same dontdiff for 2.4 and 2.6...
Jeff
On Mon, Sep 01, 2003 at 04:39:58PM +0100, Christoph Hellwig wrote:
> > I have updated dontdiff in the usual place:
> > http://www.moses.uklinux.net/patches/dontdiff
> > /usr/src/linux/Documentation/SubmittingPatches
>
> Btw, what about putting this somewhere in the kernel tree?
I do not like dontdiff to be part of the kernel tree.
What is included in dontdiff is redundant information already known
by kbuild. Effectively dontdiff should not list any files that would
not be removed during a "make mrproper".
Instead why not use the knowledge kbuild has and implement
'make dontdiff'
This could generate the list of files used for 'diff -X'.
I can try to hack up something during the week just to see if
it looks ok.
Sam
On Mon, Sep 01, 2003 at 06:22:44PM +0200, Sam Ravnborg wrote:
> On Mon, Sep 01, 2003 at 04:39:58PM +0100, Christoph Hellwig wrote:
> > > I have updated dontdiff in the usual place:
> > > http://www.moses.uklinux.net/patches/dontdiff
> > > /usr/src/linux/Documentation/SubmittingPatches
> >
> > Btw, what about putting this somewhere in the kernel tree?
>
> I do not like dontdiff to be part of the kernel tree.
> What is included in dontdiff is redundant information already known
> by kbuild. Effectively dontdiff should not list any files that would
> not be removed during a "make mrproper".
I have to agree, do not get me wrong, dontdiff might be very
useful, although I personally do not use it to create kernel
patches, but IMHO it should be autogenerated not handcrafted
best,
Herbert
> Instead why not use the knowledge kbuild has and implement
> 'make dontdiff'
>
> This could generate the list of files used for 'diff -X'.
> I can try to hack up something during the week just to see if
> it looks ok.
>
> Sam
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, Sep 01, 2003 at 01:07:41PM -0400, Jeff Garzik wrote:
>
> dontdiff must know about many things that 'make mrproper' need not care
> about:
>
> files with ".bak" suffix
> files with "~" suffix
> BitKeeper, CVS, RCS, SCCS directories
make mrproper already cares about all those.
Fragments from top-level Makefile:
RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS \) -prune -o
mrproper:
@find . $(RCS_FIND_IGNORE) \
\( -name '*.orig' -o -name '*.rej' -o -name '*~' \
-o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
-o -name '.*.rej' -o -size 0 \
-o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
-type f -print | xargs rm -f
$(call cmd,mrproper)
Sam
Sam Ravnborg wrote:
> On Mon, Sep 01, 2003 at 04:39:58PM +0100, Christoph Hellwig wrote:
>
>>>I have updated dontdiff in the usual place:
>>> http://www.moses.uklinux.net/patches/dontdiff
>>>/usr/src/linux/Documentation/SubmittingPatches
>>
>>Btw, what about putting this somewhere in the kernel tree?
>
>
> I do not like dontdiff to be part of the kernel tree.
> What is included in dontdiff is redundant information already known
> by kbuild. Effectively dontdiff should not list any files that would
> not be removed during a "make mrproper".
This is not exactly true.
dontdiff must know about many things that 'make mrproper' need not care
about:
files with ".bak" suffix
files with "~" suffix
BitKeeper, CVS, RCS, SCCS directories
etc.
On Mon, Sep 01, 2003 at 07:18:06PM +0200, Sam Ravnborg wrote:
> On Mon, Sep 01, 2003 at 01:07:41PM -0400, Jeff Garzik wrote:
> >
> > dontdiff must know about many things that 'make mrproper' need not care
> > about:
> >
> > files with ".bak" suffix
> > files with "~" suffix
> > BitKeeper, CVS, RCS, SCCS directories
>
> make mrproper already cares about all those.
> Fragments from top-level Makefile:
>
> RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS \) -prune -o
>
> mrproper:
> @find . $(RCS_FIND_IGNORE) \
> \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
> -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
> -o -name '.*.rej' -o -size 0 \
> -o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
> -type f -print | xargs rm -f
> $(call cmd,mrproper)
>
But dontdiff is a list of files that must be skipped, not a regex, right?
Then dontdiff will be useless until a build has been done on that kernel tree.
Mike Fedyk wrote:
[...]
>>mrproper:
>> @find . $(RCS_FIND_IGNORE) \
>> \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
>> -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
>> -o -name '.*.rej' -o -size 0 \
>> -o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
>> -type f -print | xargs rm -f
>> $(call cmd,mrproper)
>>
>
>
> But dontdiff is a list of files that must be skipped, not a regex, right?
> Then dontdiff will be useless until a build has been done on that kernel tree.
Not really. From the diff manpage:
-X FILE --exclude-from=FILE
Exclude files that match any pattern in FILE.
You may want to take a look at a copy of dontdiff (noting the shell
patterns). It looks like dontdiff could be generated from mrproper's
list of scratch files (with the exception of the '-size 0' test in the
'find' command) but I could be wrong.
FWIW, the $(RCS_FIND_IGNORE) part skips some version-control directories
that dontdiff doesn't mention. I guess the party line is that you should
use the version control system for doing diffs in that case, but whatever.
If you try to replace dontdiff with a dynamically generated list, be
sure and have a few folks test it out on different trees (including ones
managed by BK and SVN) to make sure you haven't broken anything.
-C
Sam Ravnborg wrote:
> On Mon, Sep 01, 2003 at 01:07:41PM -0400, Jeff Garzik wrote:
>
>>dontdiff must know about many things that 'make mrproper' need not care
>>about:
>>
>> files with ".bak" suffix
>> files with "~" suffix
>> BitKeeper, CVS, RCS, SCCS directories
>
>
> make mrproper already cares about all those.
> Fragments from top-level Makefile:
I stand corrected :) However, I think it's a tangent:
dontdiff is a file that's useful precisely because of the form its in.
So, as something that's proven itself useful to a bunch of people, I
definitely think it has a home somewhere in Documentation/* It need not
be referenced in any way by kbuild; that's not a big deal. The two
really serve different purposes.
Jeff
>>>>> "JG" == Jeff Garzik <[email protected]> writes:
JG> I stand corrected :) However, I think it's a tangent:
JG> dontdiff is a file that's useful precisely because of the form its
JG> in. So, as something that's proven itself useful to a bunch of people,
JG> I definitely think it has a home somewhere in Documentation/* It need
JG> not be referenced in any way by kbuild; that's not a big deal. The
JG> two really serve different purposes.
I do not think it is a tangent. While I am not opposed to ship
dontdiff under Documentation/* separately from the current
mrproper implementation in the Makefile, if these two should
name the identical set of paths, coming up with a scheme in
which humans have to maintain just a single source and derive
these two different usage from that single source would make
people's life easier. Two things that should be identical but
have to be kept in sync by hand is simply a maintenance
headache.
On the other hand, if there are paths that should be in dontdiff
that should not be cleaned by mrprper, or vice versa, then
keeping two separately and maintaining two independently would
absolutely makes sense. Are there such cases?
Junio C Hamano wrote:
> I do not think it is a tangent. While I am not opposed to ship
> dontdiff under Documentation/* separately from the current
> mrproper implementation in the Makefile, if these two should
> name the identical set of paths, coming up with a scheme in
> which humans have to maintain just a single source and derive
> these two different usage from that single source would make
> people's life easier. Two things that should be identical but
> have to be kept in sync by hand is simply a maintenance
> headache.
The two are maintained separately now. This is changing a file location
to make things a bit more convenient for dontdiff users; it's not
radically changing anything, technically or politically.
If there are persons that consider the presence of dontdiff in the tree
a maintenance headache, then those persons should not patch dontdiif.
Problem solved :) It's a file that's not going change often.
> On the other hand, if there are paths that should be in dontdiff
> that should not be cleaned by mrprper, or vice versa, then
> keeping two separately and maintaining two independently would
> absolutely makes sense. Are there such cases?
People are thinking _way_ too hard about this. This is just plunking a
rarely-changing file into the kernel tree. Even implying some sort of
maintenance hassle is making a mountain out of a molehill.
Jeff
On Mon, Sep 01, 2003 at 09:24:18PM -0400, Jeff Garzik wrote:
> >On Mon, Sep 01, 2003 at 01:07:41PM -0400, Jeff Garzik wrote:
> >
> >>dontdiff must know about many things that 'make mrproper' need not care
> >>about:
> >>
> >> files with ".bak" suffix
> >> files with "~" suffix
> >> BitKeeper, CVS, RCS, SCCS directories
> >
> >
> >make mrproper already cares about all those.
> >Fragments from top-level Makefile:
>
>
> I stand corrected :) However, I think it's a tangent:
>
> dontdiff is a file that's useful precisely because of the form its in.
When I proposed to autogenerate it I recalled it was a list of files,
including paths. But it is only basename used for matching.
So generating the list from within kbuild is too unsafe. There will most
likely be false negatives.
The following patch generate a list of filenames only, straight from
the kbuild Makefiles. I did not include patterns from the find
used in the top-level Makefile.
Usage: make KBUILD_DONTDIFF=1 clean
As can be seen wildcards is used in a few places
and the list of filenames generated is much bigger than included
in dontdiff today (341 files).
So I have changed my mind - do not autogenerate it. Stuff in the dontdiff
file somewhere (scripts/?).
Sam
===== scripts/Makefile.clean 1.12 vs edited =====
--- 1.12/scripts/Makefile.clean Mon Mar 10 22:03:33 2003
+++ edited/scripts/Makefile.clean Mon Sep 1 22:31:43 2003
@@ -29,14 +29,19 @@
# Add subdir path
subdir-ymn := $(addprefix $(obj)/,$(subdir-ymn))
-__clean-files := $(wildcard $(addprefix $(obj)/, \
- $(extra-y) $(EXTRA_TARGETS) $(always) $(host-progs) \
- $(targets) $(clean-files)))
+_clean-files := $(extra-y) $(EXTRA_TARGETS) $(always) $(host-progs) \
+ $(targets) $(clean-files)
# ==========================================================================
-
+ifeq ($(KBUILD_DONTDIFF),)
+__clean-files := $(wildcard $(addprefix $(obj)/,$(_clean-files)))
quiet_cmd_clean = CLEAN $(obj)
cmd_clean = rm -f $(__clean-files); $(clean-rule)
+else
+__clean-files := $(_clean-files))
+quiet_cmd_clean =
+ cmd_clean = echo $(_clean-files)
+endif
__clean: $(subdir-ymn)
ifneq ($(strip $(__clean-files) $(clean-rule)),)
>>>>> "JG" == Jeff Garzik <[email protected]> writes:
JG> People are thinking _way_ too hard about this. This is just plunking
JG> a rarely-changing file into the kernel tree. Even implying some sort
JG> of maintenance hassle is making a mountain out of a molehill.
The last sentence I agree---it is really not a big deal. But if
the thing is rarely changed, more likely people would forget to
update one when changing the other, wouldn't they?
In any case, either the dontdiff and mrproper are maintained
separately or not, I am in favor of having dontdiff in the
kernel tree.