search for: diffstats

...entry corresponds to its frequency (or in this case size).) To look at code growth between two programs, you'd do: llvm-dwarfdump size-info -baseline <object> -target <object> -stats-dir <dir> Similarly, this emits four 'view' files into <dir>, but with a *.diffstats suffix. The format is the same. Pending Work ------------ I think the main piece of work the tool needs is better testing. Currently there's just a single end-to-end test in clang. It might be better to check in a few binaries so we can check that the tool reports sizes correctly. Also, it m...

On Wed, Jan 27, 2016 at 11:57:52AM -0800, Linus Torvalds wrote: > On Wed, Jan 27, 2016 at 11:12 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > > > arch/sh/include/asm/barrier.h | 1 - > > tools/virtio/asm/barrier.h | 22 +- > > tools/virtio/linux/compiler.h | 9 + > > tools/virtio/linux/kernel.h |

On Wed, Jan 27, 2016 at 11:57:52AM -0800, Linus Torvalds wrote: > On Wed, Jan 27, 2016 at 11:12 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > > > arch/sh/include/asm/barrier.h | 1 - > > tools/virtio/asm/barrier.h | 22 +- > > tools/virtio/linux/compiler.h | 9 + > > tools/virtio/linux/kernel.h |

...uency (or in this case size).) > > To look at code growth between two programs, you'd do: > > llvm-dwarfdump size-info -baseline <object> -target <object> -stats-dir <dir> > > Similarly, this emits four 'view' files into <dir>, but with a *.diffstats > suffix. The format is the same. > > Pending Work > ------------ > > I think the main piece of work the tool needs is better testing. Currently > there's just a single end-to-end test in clang. It might be better to check in > a few binaries so we can check that the t...

...ize).) >> >> To look at code growth between two programs, you'd do: >> >> llvm-dwarfdump size-info -baseline <object> -target <object> -stats-dir <dir> >> >> Similarly, this emits four 'view' files into <dir>, but with a *.diffstats >> suffix. The format is the same. >> >> Pending Work >> ------------ >> >> I think the main piece of work the tool needs is better testing. Currently >> there's just a single end-to-end test in clang. It might be better to check in >> a few bin...

There are huge differences between source files in the version 3.0.9 released as a tar.gz and source files in git. I would assume that the released version would correspond to the version in git but with 3.0.9 it is not like that. In 3.1.0 the released and git versions are more or less the same. So my question is, from what source files was the 3.0.9 version created? Thank you. Regards, Michal

The following changes since commit a57cb1c1d7974c62a5c80f7869e35b492ace12cd: Merge branch 'akpm' (patches from Andrew) (2016-12-14 17:25:18 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 6bdf1e0efb04a1716373646cb6f35b73addca492: Makefile: drop -D__CHECK_ENDIAN__ from cflags

The following changes since commit a57cb1c1d7974c62a5c80f7869e35b492ace12cd: Merge branch 'akpm' (patches from Andrew) (2016-12-14 17:25:18 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 6bdf1e0efb04a1716373646cb6f35b73addca492: Makefile: drop -D__CHECK_ENDIAN__ from cflags

...t. In 3.1.0 the released and git versions are more or > less the same. How did you construct this? I can't reproduce your result. The only differences I see are the generated files proto.h, rsync.1, and rsyncd.conf.5. Here's my test steps, with the output of everything except the final diffstats omitted. $ cd /tmp $ tar xvf .../rsync-3.0.9.tar.gz $ tar xvf .../rsync-3.1.0.tar.gz $ git clone --bare git://git.samba.org/rsync.git /tmp/rsync-git-bare/ $ GIT_DIR=/tmp/rsync-git-bare git worktree add /tmp/rsync-git-3.0.9 v3.0.9 $ GIT_DIR=/tmp/rsync-git-bare git worktree add /tmp/rsync-git-3.1.0...

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 481eaec37e91e2b33f17275901172f50ce2c71e8: tools/virtio: add ringtest utilities (2016-01-26 10:18:30 +0200)

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 481eaec37e91e2b33f17275901172f50ce2c71e8: tools/virtio: add ringtest utilities (2016-01-26 10:18:30 +0200)

from: Jeff Sloan <jeff_sloan at selinc.com> Update UEFI PXE proxyDHCP handling updated. This patch is based on commit ID 8a00e49 Updated pxe.c and udp.c to incorporate feedback.In addition to the previous modifications: pxe.c: Changed to use ProxyOffer Packet and added client ip from PxeReply into temp packet for parsing. Left all existing cached packets untouched. udp.c:

On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh at linuxfoundation.org> wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > > From: Tom Rix <trix at redhat.com> > > > > This is a upcoming change to clean up a new warning treewide. > > I am wondering if the change could be one mega patch (see below) or > > normal patch

On 11/17/2017 12:28 PM, Eric Blake wrote: >> There's nothing wrong with this patch, but it might be easier to use >> an attribute((cleanup)) handler to deal with the unlocking. See these >> links for how we do it in libguestfs: > > Oh cool! Yes, that looks nicer. Although the diffstat for doing so is > larger, because it requires adding to new sub-function {}

On 2019-06-13 12:27 p.m., Dan Williams wrote: > On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig <hch at lst.de> wrote: >> >> Hi Dan, Jérôme and Jason, >> >> below is a series that cleans up the dev_pagemap interface so that >> it is more easily usable, which removes the need to wrap it in hmm >> and thus allowing to kill a lot of code >>

The Asterisk Development Team has announced the releases of: DAHDI-Linux-v2.11.1-rc1 DAHDI-Tools-v2.11.1-rc1 dahdi-linux-complete-2.11.1-rc1+2.11.1-rc1 This release is available for immediate download at: http://downloads.asterisk.org/pub/telephony/dahdi-linux http://downloads.asterisk.org/pub/telephony/dahdi-tools http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete Notable changes:

...gt;> >> Anyway, pulled. Just curious about how that thing happened. > > That's because apparently diffstat obeys orderfile rules: Ugh. I guess that makes sense, but it's still very annoying for something like a pull request, where now different people end up having different diffstats. And the reason I never noticed it is that likely there aren't that many people who use an orderfile. I guess something like "-O /dev/null" in the pull-request would undo it, but it is a bit annoying. I've never actually met anybody (knowingly) that used that option. I thought i...

...el/git/mst/vhost.git tags/for_linus Pulled, but I wonder... > Documentation/translations/zh_CN/sparse.txt | 7 +- > arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +- > drivers/crypto/virtio/virtio_crypto_common.h | 128 +++++ [...] what are you generating these diffstats with? Because they are pretty bogus.. The end result is correct: > 86 files changed, 2106 insertions(+), 280 deletions(-) but the file order in the diffstat is completely random, which makes it very hard to compare with what I get. It also makes it hard to see what you changed, because it...

...; Pulled, but I wonder... > > > Documentation/translations/zh_CN/sparse.txt | 7 +- > > arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +- > > drivers/crypto/virtio/virtio_crypto_common.h | 128 +++++ > [...] > > what are you generating these diffstats with? Because they are pretty bogus.. > > The end result is correct: > > > 86 files changed, 2106 insertions(+), 280 deletions(-) > > but the file order in the diffstat is completely random, which makes > it very hard to compare with what I get. It also makes it hard to...

...; Pulled, but I wonder... > > > Documentation/translations/zh_CN/sparse.txt | 7 +- > > arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +- > > drivers/crypto/virtio/virtio_crypto_common.h | 128 +++++ > [...] > > what are you generating these diffstats with? Because they are pretty bogus.. > > The end result is correct: > > > 86 files changed, 2106 insertions(+), 280 deletions(-) > > but the file order in the diffstat is completely random, which makes > it very hard to compare with what I get. It also makes it hard to...