On Tue, Mar 13, 2018 at 4:08 AM, Dmitry Vyukov wrote:
> On Tue, Mar 13, 2018 at 1:46 PM, Peter Zijlstra wrote:
>>
>>> >> b06ed71a6 Dmitry Vyukov 2018-01-29 283 static __always_inline unsigned
>>> >> long
>>> >> b06ed71a6 Dmitry Vyukov 2018-01-29 284
On Tue, Mar 13, 2018 at 4:08 AM, Dmitry Vyukov wrote:
> On Tue, Mar 13, 2018 at 1:46 PM, Peter Zijlstra wrote:
>>
>>> >> b06ed71a6 Dmitry Vyukov 2018-01-29 283 static __always_inline unsigned
>>> >> long
>>> >> b06ed71a6 Dmitry Vyukov 2018-01-29 284 cmpxchg_size(volatile void
>>> >> *ptr,
On Wed, Jul 26, 2017 at 9:33 AM, Lance Richardson wrote:
> Hmm, it seems sparse is incorrectly taking ~0UL to be a 64-bit value
> while BITS_PER_LONG is (correctly) evaluated to be 32.
>
> #define GENMASK(h, l) \
> (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 -
On Wed, Jul 26, 2017 at 9:33 AM, Lance Richardson wrote:
> Hmm, it seems sparse is incorrectly taking ~0UL to be a 64-bit value
> while BITS_PER_LONG is (correctly) evaluated to be 32.
>
> #define GENMASK(h, l) \
> (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
>
What is the
On Fri, Jul 7, 2017 at 8:48 AM, Linus Torvalds
wrote:
> The releases are done way too seldom to be useful, but that may be
> improving. There is one fairly imminent, and it's probably a good idea
> to just test the current git tree.
Yes guilty of too few releases.
On Fri, Jul 7, 2017 at 8:48 AM, Linus Torvalds
wrote:
> The releases are done way too seldom to be useful, but that may be
> improving. There is one fairly imminent, and it's probably a good idea
> to just test the current git tree.
Yes guilty of too few releases. We are cutting one release
On Thu, Aug 11, 2016 at 6:39 PM, Johannes Berg
wrote:
> Since gcc does this, it's apparently valid to write
>
> switch (x) {
> case __builtin_bswap16(12):
>break;
> }
>
> but sparse will flag it as an error today.
>
> The constant folding used to be done in the
On Thu, Aug 11, 2016 at 6:39 PM, Johannes Berg
wrote:
> Since gcc does this, it's apparently valid to write
>
> switch (x) {
> case __builtin_bswap16(12):
>break;
> }
>
> but sparse will flag it as an error today.
>
> The constant folding used to be done in the kernel's htons() and
>
imilar.
>
> Adding Christopher Li to the recipient list - any thoughts?
Yes, I should cut a new release long time ago. Let me just do that.
Chris
On Tue, Mar 15, 2016 at 4:19 AM, wrote:
>
> Fedora only packaged 0.5.0, which doesn't include the last few
> dozen commits. And they probably won't update until a sparse maintainer
> sticks a v0.5.1 tag on it. I suspect that other distros are similar.
>
> Adding Christopher L
On Wed, Feb 17, 2016 at 1:51 AM, Daniel Wagner
wrote:
>
> Maybe the first 3 patches might be okay to get merged.
Yes, the first 3 looks simple and obvious correct.
Chris
On Wed, Feb 17, 2016 at 1:51 AM, Daniel Wagner
wrote:
>
> Maybe the first 3 patches might be okay to get merged.
Yes, the first 3 looks simple and obvious correct.
Chris
On Sun, Apr 26, 2015 at 10:20 PM, Fengguang Wu wrote:
>> >
>> > drivers/dma/xgene-dma.c:2088:1: sparse: symbol
>> > '__UNIQUE_ID_author__COUNTER__' has multiple initializers (originally
>> > initialized at drivers/dma/xgene-dma.c:2087)
>> > So, I kept only one author here.
>> No that is not
On Sun, Apr 26, 2015 at 10:20 PM, Fengguang Wu fengguang...@intel.com wrote:
drivers/dma/xgene-dma.c:2088:1: sparse: symbol
'__UNIQUE_ID_author__COUNTER__' has multiple initializers (originally
initialized at drivers/dma/xgene-dma.c:2087)
So, I kept only one author here.
No that is not
On Thu, Dec 18, 2014 at 6:37 AM, Murali Karicheri wrote:
> if (!ks_pcie) {
> dev_err(dev, "no memory for keystone pcie\n");
> return -ENOMEM;
> }
> pp = _pcie->pp;
>
> /* initialize SerDes Phy if present */
> phy =
On Thu, Dec 18, 2014 at 6:37 AM, Murali Karicheri m-kariche...@ti.com wrote:
if (!ks_pcie) {
dev_err(dev, no memory for keystone pcie\n);
return -ENOMEM;
}
pp = ks_pcie-pp;
/* initialize SerDes Phy if present */
phy =
On Tue, Jul 8, 2014 at 12:37 AM, Dan Carpenter wrote:
> My kernel tree is full of drivers/foo.c.smatch and
> drivers/foo.c.smatch-info files...
>
> It would be nice to add it to .gitignore as well.
Actually, ".*" is already in the .gitignore, there for the sparse log files
are covered.
Chris
--
On Tue, Jul 8, 2014 at 12:37 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
My kernel tree is full of drivers/foo.c.smatch and
drivers/foo.c.smatch-info files...
It would be nice to add it to .gitignore as well.
Actually, .* is already in the .gitignore, there for the sparse log files
are
On Mon, Jul 7, 2014 at 4:22 AM, Sam Ravnborg wrote:
>> > Typical usage:
>> >
>> > make -j8 C=2 CLOG=
>>
> We do not need this kind of special handling of outputs from gcc.
> For sparse you just do a run with C=2 then you have it.
>
> In other words - this looks like overkill for somethign thas
On Mon, Jul 7, 2014 at 4:22 AM, Sam Ravnborg s...@ravnborg.org wrote:
Typical usage:
make -j8 C=2 CLOG=logname
We do not need this kind of special handling of outputs from gcc.
For sparse you just do a run with C=2 then you have it.
In other words - this looks like overkill for
On Mon, Jun 30, 2014 at 1:57 AM, Christopher Li wrote:
>
> Add the CLOG= option in command line to
> save the sparse warning into individual log file.
>
> Typical usage:
>
> make -j8 C=2 CLOG=
Any feed back for this change? I want to clarify that this patch
is for the Linux
On Mon, Jun 30, 2014 at 1:57 AM, Christopher Li spa...@chrisli.org wrote:
Add the CLOG=logname option in command line to
save the sparse warning into individual log file.
Typical usage:
make -j8 C=2 CLOG=logname
Any feed back for this change? I want to clarify that this patch
=
The log file is saved in the target directory as
.xxx.o..sparse
By diffing between different log file, it is much
easier to analyze how the sparse change impact
the whole kernel build.
Signed-off-by: Christopher Li
Chris
From 3b2ff204cbda684adf9dba2adf568062533ae34d Mon Sep 17 00:00:00 2001
From
On Mon, Jun 30, 2014 at 1:32 AM, Andy Shevchenko
wrote:
>
> Hmm... I'd just added test printf to the handle_param() and see if I
> print *next, it is either --param or --param=*. So, using return (next +
> 2) helps, otherwise we end up with the same situation as before patch.
The return value
On Mon, Jun 30, 2014 at 1:32 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
Hmm... I'd just added test printf to the handle_param() and see if I
print *next, it is either --param or --param=*. So, using return (next +
2) helps, otherwise we end up with the same situation as
CLOG=logname
The log file is saved in the target directory as
.xxx.o.logname.sparse
By diffing between different log file, it is much
easier to analyze how the sparse change impact
the whole kernel build.
Signed-off-by: Christopher Li spa...@chrisli.org
Chris
From
On Sun, Jun 29, 2014 at 12:19 AM, Christopher Li wrote:
>
> If no objections, I will push the change.
>
Change pushed.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
Hi Andy,
On Sat, Jun 28, 2014 at 9:59 AM, Christopher Li wrote:
> I think this is problematic.There are three possible input
> from args:
> 1) "--parm", you need to ++next skip to next arg, which is the value for parm.
> 2) "--parm=x", you don't need to skip to
Hi Andy,
On Sat, Jun 28, 2014 at 9:59 AM, Christopher Li spa...@chrisli.org wrote:
I think this is problematic.There are three possible input
from args:
1) --parm, you need to ++next skip to next arg, which is the value for parm.
2) --parm=x, you don't need to skip to next arg.
3) --parm
On Sun, Jun 29, 2014 at 12:19 AM, Christopher Li spa...@chrisli.org wrote:
If no objections, I will push the change.
Change pushed.
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Oops, I just click send before I type up the reply. Here we go again.
On Tue, Jun 17, 2014 at 2:11 AM, Andy Shevchenko
wrote:
> Very dumb patch to just skip --param allow-store-data-races=0 introduced in
> newer GCC versions.
>
> +static char **handle_param(char *arg, char **next)
> +{
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Oops, I just click send before I type up the reply. Here we go again.
On Tue, Jun 17, 2014 at 2:11 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
Very dumb patch to just skip --param allow-store-data-races=0 introduced in
newer GCC versions.
+static char **handle_param(char
On Tue, May 6, 2014 at 1:47 AM, Dan Carpenter wrote:
>> diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
>> b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
>> index 426f223..c96dbab 100644
>> --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
>> +++
On Tue, May 6, 2014 at 1:47 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index 426f223..c96dbab 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++
On Tue, May 6, 2014 at 1:47 AM, Dan Carpenter wrote:
>> - boolsearch_dir[4] = {0, 0, 0, 0};
>> + boolsearch_dir[4] = {0};
>
> That's weird. The original code is valid but it generates a sparse
> warning.
>
>
On Tue, May 6, 2014 at 1:47 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
- boolsearch_dir[4] = {0, 0, 0, 0};
+ boolsearch_dir[4] = {0};
That's weird. The original code is valid but it generates a sparse
warning.
On Thu, Feb 27, 2014 at 1:00 PM, Joe Perches wrote:
> Of course
>
The change has applied and pushed.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, Feb 27, 2014 at 1:00 PM, Joe Perches wrote:
> On Thu, 2014-02-27 at 12:44 -0800, Christopher Li wrote:
>> On Thu, Feb 27, 2014 at 12:26 PM, H. Peter Anvin wrote:
>> > I would.
>> Joe, I assume you are OK with this patch, the default is now off.
>
> Of course
son to use bits_in_ is to allow sparse application to over write
the size of int etc. If you don't like the bits_in_char here. You can introduce
bits_in_bool and set that to sizeof(Bool)*8 by default. That way you don't
hard code it.
> And also, in sparse.1, Josh Triplett is shown as
> the ma
erches
Reviewed-by: Josh Triplett
Signed-off-by: Christopher Li
---
evaluate.c | 3 ++-
lib.c | 2 ++
lib.h | 1 +
sparse.1 | 8
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/evaluate.c b/evaluate.c
index 6655615..a45f59b 100644
--- a/evaluate.c
+++ b/evaluate.c
@@
On Wed, Feb 26, 2014 at 8:32 PM, H. Peter Anvin wrote:
>
> Quite frankly, this is silly in my opinion, *and* it is not guaranteed
> by C either (read about "trap representations").
>>
> Anything that moves data around in a generic fashion. It can be as
> simple as:
>
> memcpy(foo, bar,
On Wed, Feb 26, 2014 at 8:32 PM, H. Peter Anvin h...@zytor.com wrote:
Quite frankly, this is silly in my opinion, *and* it is not guaranteed
by C either (read about trap representations).
Anything that moves data around in a generic fashion. It can be as
simple as:
memcpy(foo,
...@perches.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
Signed-off-by: Christopher Li spa...@chrisli.org
---
evaluate.c | 3 ++-
lib.c | 2 ++
lib.h | 1 +
sparse.1 | 8
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/evaluate.c b/evaluate.c
index 6655615
. You can introduce
bits_in_bool and set that to sizeof(Bool)*8 by default. That way you don't
hard code it.
And also, in sparse.1, Josh Triplett is shown as
the maintainer. Maybe that should be changed to
Christopher Li
Maybe a separate patch.
Waiting for your V3.
Chris
--
To unsubscribe
On Thu, Feb 27, 2014 at 1:00 PM, Joe Perches j...@perches.com wrote:
On Thu, 2014-02-27 at 12:44 -0800, Christopher Li wrote:
On Thu, Feb 27, 2014 at 12:26 PM, H. Peter Anvin h...@zytor.com wrote:
I would.
Joe, I assume you are OK with this patch, the default is now off.
Of course
Let me
On Thu, Feb 27, 2014 at 1:00 PM, Joe Perches j...@perches.com wrote:
Of course
The change has applied and pushed.
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Wed, May 8, 2013 at 12:42 AM, Dan Carpenter wrote:
> Sparse generates a false positive when you pass a __user or __iomem
> pointer to the IS_ERR() functions.
>
> drivers/rtc/rtc-ds1286.c:344:36: sparse: incorrect type in argument 1
> (different address spaces)
>
On Wed, May 8, 2013 at 12:42 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
Sparse generates a false positive when you pass a __user or __iomem
pointer to the IS_ERR() functions.
drivers/rtc/rtc-ds1286.c:344:36: sparse: incorrect type in argument 1
(different address spaces)
gument. It is OK to pass __iomem pointer to "ptr".
The example are in the patch. It need to patch both sparse and the
Linux tree.
What do you say?
Chris
>From a0974ed0fc1e67c41608c780b748c205622956b8 Mon Sep 17 00:00:00 2001
From: Christopher Li
Date: Thu, 25 Apr 2013 18:09:43
to ptr.
The example are in the patch. It need to patch both sparse and the
Linux tree.
What do you say?
Chris
From a0974ed0fc1e67c41608c780b748c205622956b8 Mon Sep 17 00:00:00 2001
From: Christopher Li spa...@chrisli.org
Date: Thu, 25 Apr 2013 18:09:43 -0700
Subject: [PATCH] Allow forced
On Mon, Apr 22, 2013 at 4:56 PM, Andrew Morton
wrote:
> I think doing IS_ERR() and PTR_ERR() on __iomem pointers is a natural
> thing, and we should be able to do this without adding call-site
> trickery to make sparse happy.
>
> Is there some sort of annotation which we can add to the
>
On Mon, Apr 22, 2013 at 4:56 PM, Andrew Morton
a...@linux-foundation.org wrote:
I think doing IS_ERR() and PTR_ERR() on __iomem pointers is a natural
thing, and we should be able to do this without adding call-site
trickery to make sparse happy.
Is there some sort of annotation which we can
Let me add a signed off in case some one want to apply it.
Signed-Off-By: Christopher Li
On Wed, Mar 20, 2013 at 1:19 PM, Sam Ravnborg wrote:
> I looked at the attached patch:
> Acked-by: Sam Ravnborg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
Let me add a signed off in case some one want to apply it.
Signed-Off-By: Christopher Li spa...@chrisli.org
On Wed, Mar 20, 2013 at 1:19 PM, Sam Ravnborg s...@ravnborg.org wrote:
I looked at the attached patch:
Acked-by: Sam Ravnborg s...@ravnborg.org
--
To unsubscribe from this list: send
On Sun, Mar 17, 2013 at 2:58 PM, Sam Ravnborg wrote:
>
> We got no patch - just some git help stuff.
> Seems you mistyped somthing..
>
Oops, sorry about that. I reattach the patch here.
Chris
kbuild-avoid-rebuild-some-object.patch
Description: Binary data
In the current tip of git tree. If I do a allmodconfig full build, then follow
by a "make" again without changing any code in the tree.
There are some object will always get rebuild. e.g. eboot.o.
I use "make V=2", it shows that the rebuild is due to some object file
not in $(targets). I did not
In the current tip of git tree. If I do a allmodconfig full build, then follow
by a make again without changing any code in the tree.
There are some object will always get rebuild. e.g. eboot.o.
I use make V=2, it shows that the rebuild is due to some object file
not in $(targets). I did not
On Sun, Mar 17, 2013 at 2:58 PM, Sam Ravnborg s...@ravnborg.org wrote:
We got no patch - just some git help stuff.
Seems you mistyped somthing..
Oops, sorry about that. I reattach the patch here.
Chris
kbuild-avoid-rebuild-some-object.patch
Description: Binary data
On Sat, Mar 9, 2013 at 2:34 PM, Dan Carpenter wrote:
> The problems is if we go over the 8k stack. So big arrays are bad.
> Also if the dynamically sized array is inside a loop then normally
> GCC frees it after each iteration, but on some arches it didn't free
> it until after the last
On Fri, Mar 8, 2013 at 9:39 PM, Dan Carpenter wrote:
> On Fri, Mar 08, 2013 at 04:29:22PM -0800, Andrew Morton wrote:
>> Roughly how many instances of this are there kernel-wide?
>>
>
> Around 150 on x86 allmodconfig. They are pretty well audited.
I saw 207 on x86-64 allmodconfig. See the list
On Fri, Mar 8, 2013 at 9:39 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
On Fri, Mar 08, 2013 at 04:29:22PM -0800, Andrew Morton wrote:
Roughly how many instances of this are there kernel-wide?
Around 150 on x86 allmodconfig. They are pretty well audited.
I saw 207 on x86-64
On Sat, Mar 9, 2013 at 2:34 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
The problems is if we go over the 8k stack. So big arrays are bad.
Also if the dynamically sized array is inside a loop then normally
GCC frees it after each iteration, but on some arches it didn't free
it until
Hi,
I am looking at the current sparse warning on the kernel source.
One category of those warning are produce by the variable length array.
We all know that the kernel stack has a limit so we don't want to allocate
too much stack to the variable size array.
Is there a recommended way to fix
Hi,
I am looking at the current sparse warning on the kernel source.
One category of those warning are produce by the variable length array.
We all know that the kernel stack has a limit so we don't want to allocate
too much stack to the variable size array.
Is there a recommended way to fix
On Sat, Mar 2, 2013 at 5:23 AM, Fengguang Wu wrote:
> That's it! Verified with
>
> make C=1 kernel/trace/trace_functions.o
You can use C=2 to run sparse without recompile the obj file.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sat, Mar 2, 2013 at 5:23 AM, Fengguang Wu fengguang...@intel.com wrote:
That's it! Verified with
make C=1 kernel/trace/trace_functions.o
You can use C=2 to run sparse without recompile the obj file.
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
nction entry, exit, or
> both.
>
> Signed-off-by: Ed Cashin
Signed-off-by: Christopher Li
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/
on function entry, exit, or
both.
Signed-off-by: Ed Cashin ecas...@coraid.com
Signed-off-by: Christopher Li spa...@chrisli.org
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
OK, I get a trivial fix after all. The test case is fixed now.
I haven't done much test otherwise.
See the patch attached.
Chris
On 10/19/07, Chris Li <[EMAIL PROTECTED]> wrote:
> Err,
>
> Sparse does not support the local label syntax yet. It just treats the
> second label "x:" as the same as
OK, I get a trivial fix after all. The test case is fixed now.
I haven't done much test otherwise.
See the patch attached.
Chris
On 10/19/07, Chris Li [EMAIL PROTECTED] wrote:
Err,
Sparse does not support the local label syntax yet. It just treats the
second label x: as the same as the
On Mon, Mar 26, 2007 at 02:59:39PM -0400, Russ Cox wrote:
> No, you have it backward.
> It is valid to pass void* to a const void* function.
> It is *not* valid to pass const void* to a void* function.
>
> Right now __chk_user_ptr is a void* function, meaning
> that all the places where it gets
On Mon, Mar 26, 2007 at 11:23:56AM -0400, Russ Cox wrote:
> Change prototypes for __chk_user_ptr and __chk_io_ptr
> to take const void* instead of void*, so that code can pass
> const void* to them. (Right now sparse does not warn
> about passing const void* to void* functions, but that
> is a
On Mon, Mar 26, 2007 at 11:23:56AM -0400, Russ Cox wrote:
Change prototypes for __chk_user_ptr and __chk_io_ptr
to take const void* instead of void*, so that code can pass
const void* to them. (Right now sparse does not warn
about passing const void* to void* functions, but that
is a
On Mon, Mar 26, 2007 at 02:59:39PM -0400, Russ Cox wrote:
No, you have it backward.
It is valid to pass void* to a const void* function.
It is *not* valid to pass const void* to a void* function.
Right now __chk_user_ptr is a void* function, meaning
that all the places where it gets passed
On Sun, Feb 11, 2007 at 05:50:15AM +, Al Viro wrote:
>
> I have some stuff in that direction, but it take some resurrecting...
OK, we should talk.
Here is what I have:
Linearize bytecode writer, which produce the binary linearized code.
The uncompress size is about 10 times the i386 .o
On Sat, Feb 10, 2007 at 06:33:25PM +0100, Andi Kleen wrote:
> Interesting. Did you find any kernel bugs with this?
In short, not very useful yet.
The current run of of sparse-0.2-cl2 on git default i386 config
will find about 6 place kernel using allocated memory without NULL
check. But Linus
On Sat, Feb 10, 2007 at 06:33:25PM +0100, Andi Kleen wrote:
Interesting. Did you find any kernel bugs with this?
In short, not very useful yet.
The current run of of sparse-0.2-cl2 on git default i386 config
will find about 6 place kernel using allocated memory without NULL
check. But Linus
On Sun, Feb 11, 2007 at 05:50:15AM +, Al Viro wrote:
I have some stuff in that direction, but it take some resurrecting...
OK, we should talk.
Here is what I have:
Linearize bytecode writer, which produce the binary linearized code.
The uncompress size is about 10 times the i386 .o file.
Temporarily at:
http://userweb.kernel.org/~chrisl/sparse-0.2-cl2
Will appear later at:
http://ftp.kernel.org//pub/linux/kernel/people/chrisl/patches/sparse/sparse-0.2-cl2/
I have been play with sparse to add more Stanford checker style
of checking. The paper is "Checking System Rules
Temporarily at:
http://userweb.kernel.org/~chrisl/sparse-0.2-cl2
Will appear later at:
http://ftp.kernel.org//pub/linux/kernel/people/chrisl/patches/sparse/sparse-0.2-cl2/
I have been play with sparse to add more Stanford checker style
of checking. The paper is Checking System Rules
I see. It just need some basic set operation (+, -, and)
and some way to select a set:
sha5--->
/
/
sha1-->sha2-->sha3--
\/
\ /
>sha4
list sha1 # all the file list in changeset sha1
# {sha1}
list sha1,sha1
On Sun, Apr 10, 2005 at 03:38:39PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 10 Apr 2005, Christopher Li wrote:
> >
> > BTW, one thing I learn from ext3 is that it is very useful to have some
> > compatible flag for future development. I think if we want to reserv
On Sun, Apr 10, 2005 at 01:57:33PM -0700, Linus Torvalds wrote:
>
> > That way of thinking really doesn't work well here.
> >
> > I will have to look more closely at pasky's GIT toolkit
> > if I want to see an SCM style interface.
>
> Yes. You really should think of GIT as a filesystem, and of
I totally agree that odds is really really small.
That is why it is not worthy to handle the case. People hit that
can just add a new line or some thing to avoid it, if
it happen after all.
It is the little peace of mind to know for sure that did
not happen. I am just paranoid.
Chris
On Sun,
On Sun, Apr 10, 2005 at 11:41:53AM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Apr 10, 2005 at 07:53:40AM CEST, I got a letter
> where Christopher Li <[EMAIL PROTECTED]> told me that...
> > On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
> > >
&g
On Sun, Apr 10, 2005 at 02:28:54AM -0700, Junio C Hamano wrote:
> >>>>> "CL" == Christopher Li <[EMAIL PROTECTED]> writes:
>
> CL> On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
> >>
> >> But I am wondering wha
On Sat, Apr 09, 2005 at 04:31:10PM -0700, Linus Torvalds wrote:
>
> Done, and pushed out. The current git.git repository seems to do all of
> this correctly.
>
> NOTE! This means that each "tree" file basically tracks just a single
> directory. The old style of "every file in one tree file"
On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
>
> But I am wondering what your plans are to handle renames---or
> does git already represent them?
>
Rename should just work. It will create a new tree object and you
will notice that in the entry that changed, the hash for the
On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
But I am wondering what your plans are to handle renames---or
does git already represent them?
Rename should just work. It will create a new tree object and you
will notice that in the entry that changed, the hash for the blob
On Sat, Apr 09, 2005 at 04:31:10PM -0700, Linus Torvalds wrote:
Done, and pushed out. The current git.git repository seems to do all of
this correctly.
NOTE! This means that each tree file basically tracks just a single
directory. The old style of every file in one tree file still works,
On Sun, Apr 10, 2005 at 02:28:54AM -0700, Junio C Hamano wrote:
CL == Christopher Li [EMAIL PROTECTED] writes:
CL On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
But I am wondering what your plans are to handle renames---or
does git already represent them?
CL
On Sun, Apr 10, 2005 at 11:41:53AM +0200, Petr Baudis wrote:
Dear diary, on Sun, Apr 10, 2005 at 07:53:40AM CEST, I got a letter
where Christopher Li [EMAIL PROTECTED] told me that...
On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
But I am wondering what your plans
I totally agree that odds is really really small.
That is why it is not worthy to handle the case. People hit that
can just add a new line or some thing to avoid it, if
it happen after all.
It is the little peace of mind to know for sure that did
not happen. I am just paranoid.
Chris
On Sun,
On Sun, Apr 10, 2005 at 01:57:33PM -0700, Linus Torvalds wrote:
That way of thinking really doesn't work well here.
I will have to look more closely at pasky's GIT toolkit
if I want to see an SCM style interface.
Yes. You really should think of GIT as a filesystem, and of me as a
On Sun, Apr 10, 2005 at 03:38:39PM -0700, Linus Torvalds wrote:
On Sun, 10 Apr 2005, Christopher Li wrote:
BTW, one thing I learn from ext3 is that it is very useful to have some
compatible flag for future development. I think if we want to reserve some
room in the file format
I see. It just need some basic set operation (+, -, and)
and some way to select a set:
sha5---
/
/
sha1--sha2--sha3--
\/
\ /
sha4
list sha1 # all the file list in changeset sha1
# {sha1}
list sha1,sha1 #
That design sounds bad.
Anyway, I guess the error you are getting might have some thing to do with
the "." and ".." entry. Your current directory need to in the same
format as well. That is the price you pay for breaking the compatibility.
Chris
On Mon, Apr 04, 2005 at 08:08:57PM -0400, Vineet
That design sounds bad.
Anyway, I guess the error you are getting might have some thing to do with
the . and .. entry. Your current directory need to in the same
format as well. That is the price you pay for breaking the compatibility.
Chris
On Mon, Apr 04, 2005 at 08:08:57PM -0400, Vineet
1 - 100 of 114 matches
Mail list logo