* [PATCH/RFC 1/7] i18n: mark init-db messages for translation
From: Ævar Arnfjörð Bjarmason @ 2011-04-10 19:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason
In-Reply-To: <1302464048-21806-1-git-send-email-avarab@gmail.com>
Mark the init-db messages that were added in v1.7.5-rc1~16^2 (init,
clone: support --separate-git-dir for .git file) by Nguyễn Thái Ngọc
Duy for translation.
This requires splitting up the tests that the patch added so that
certain parts of them can be skipped unless the C_LOCALE_OUTPUT
prerequisite is satisfied.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
builtin/init-db.c | 12 ++++++------
t/t0001-init.sh | 28 ++++++++++++++++++++--------
t/t5601-clone.sh | 7 +++++--
3 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index b7370d9..6d0a856 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -319,10 +319,10 @@ int set_git_dir_init(const char *git_dir, const char *real_git_dir,
struct stat st;
if (!exist_ok && !stat(git_dir, &st))
- die("%s already exists", git_dir);
+ die(_("%s already exists"), git_dir);
if (!exist_ok && !stat(real_git_dir, &st))
- die("%s already exists", real_git_dir);
+ die(_("%s already exists"), real_git_dir);
/*
* make sure symlinks are resolved because we'll be
@@ -351,16 +351,16 @@ static void separate_git_dir(const char *git_dir)
else if (S_ISDIR(st.st_mode))
src = git_link;
else
- die("unable to handle file type %d", st.st_mode);
+ die(_("unable to handle file type %d"), st.st_mode);
if (rename(src, git_dir))
- die_errno("unable to move %s to %s", src, git_dir);
+ die_errno(_("unable to move %s to %s"), src, git_dir);
}
fp = fopen(git_link, "w");
if (!fp)
- die("Could not create git link %s", git_link);
- fprintf(fp, "gitdir: %s\n", git_dir);
+ die(_("Could not create git link %s"), git_link);
+ fprintf(fp, _("gitdir: %s\n"), git_dir);
fclose(fp);
}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index a5816d0..fa31cbd 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -374,22 +374,28 @@ test_expect_success 'init prefers command line to GIT_DIR' '
test_expect_success 'init with separate gitdir' '
rm -rf newdir &&
git init --separate-git-dir realgitdir newdir &&
- echo "gitdir: `pwd`/realgitdir" >expected &&
- test_cmp expected newdir/.git &&
test -d realgitdir/refs
'
+test_expect_success C_LOCALE_OUTPUT 'init with separate gitdir: output' '
+ echo "gitdir: `pwd`/realgitdir" >expected &&
+ test_cmp expected newdir/.git
+'
+
test_expect_success 're-init to update git link' '
(
cd newdir &&
git init --separate-git-dir ../surrealgitdir
) &&
- echo "gitdir: `pwd`/surrealgitdir" >expected &&
- test_cmp expected newdir/.git &&
test -d surrealgitdir/refs &&
! test -d realgitdir/refs
'
+test_expect_success C_LOCALE_OUTPUT 're-init to update git link: output' '
+ echo "gitdir: `pwd`/surrealgitdir" >expected &&
+ test_cmp expected newdir/.git
+'
+
test_expect_success 're-init to move gitdir' '
rm -rf newdir realgitdir surrealgitdir &&
git init newdir &&
@@ -397,11 +403,14 @@ test_expect_success 're-init to move gitdir' '
cd newdir &&
git init --separate-git-dir ../realgitdir
) &&
- echo "gitdir: `pwd`/realgitdir" >expected &&
- test_cmp expected newdir/.git &&
test -d realgitdir/refs
'
+test_expect_success C_LOCALE_OUTPUT 're-init to move gitdir: output' '
+ echo "gitdir: `pwd`/realgitdir" >expected &&
+ test_cmp expected newdir/.git
+'
+
test_expect_success 're-init to move gitdir symlink' '
rm -rf newdir realgitdir &&
git init newdir &&
@@ -411,10 +420,13 @@ test_expect_success 're-init to move gitdir symlink' '
ln -s here .git &&
git init -L ../realgitdir
) &&
- echo "gitdir: `pwd`/realgitdir" >expected &&
- test_cmp expected newdir/.git &&
test -d realgitdir/refs &&
! test -d newdir/here
'
+test_expect_success C_LOCALE_OUTPUT 're-init to move gitdir symlink: output' '
+ echo "gitdir: `pwd`/realgitdir" >expected &&
+ test_cmp expected newdir/.git
+'
+
test_done
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 5a068b2..a50e36e 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -194,11 +194,14 @@ test_expect_success 'do not respect url-encoding of non-url path' '
test_expect_success 'clone separate gitdir' '
rm -rf dst &&
git clone --separate-git-dir realgitdir src dst &&
- echo "gitdir: `pwd`/realgitdir" >expected &&
- test_cmp expected dst/.git &&
test -d realgitdir/refs
'
+test_expect_success C_LOCALE_OUTPUT 'clone separate gitdir: output' '
+ echo "gitdir: `pwd`/realgitdir" >expected &&
+ test_cmp expected dst/.git
+'
+
test_expect_success 'clone separate gitdir where target already exists' '
rm -rf dst &&
test_must_fail git clone --separate-git-dir realgitdir src dst
--
1.7.4.1
^ permalink raw reply related
* [PATCH/RFC 2/7] i18n: mark merge "Could not read from" message for translation
From: Ævar Arnfjörð Bjarmason @ 2011-04-10 19:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason
In-Reply-To: <1302464048-21806-1-git-send-email-avarab@gmail.com>
Mark the "Could not read from '%s'" message that was added to
builtin/merge.c in v1.7.4.2~25^2 (merge: honor prepare-commit-msg
hook) by Jay Soffian for translation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
builtin/merge.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index d54e7dd..7eda05d 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -822,7 +822,7 @@ static void read_merge_msg(void)
{
strbuf_reset(&merge_msg);
if (strbuf_read_file(&merge_msg, git_path("MERGE_MSG"), 0) < 0)
- die_errno("Could not read from '%s'", git_path("MERGE_MSG"));
+ die_errno(_("Could not read from '%s'"), git_path("MERGE_MSG"));
}
static void run_prepare_commit_msg(void)
--
1.7.4.1
^ permalink raw reply related
* [PATCH/RFC 0/7] i18n: mark missing C messages
From: Ævar Arnfjörð Bjarmason @ 2011-04-10 19:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason
Some messages fell through the cracks during the later submissions of
the i18n series, hopefully this catches all of the remaining C
messsages.
This is an RFC because the first patch still leaves one remaining
gitdir test failing under GETTEXT_POISON, and I won't be able to find
out why tonight. Help welcome with figuring out why (in which case
this should all be OK), you just need too build with
GETTEXT_POISON=YesPlease and run t/t0001-init.sh.
Ævar Arnfjörð Bjarmason (7):
i18n: mark init-db messages for translation
i18n: mark merge "Could not read from" message for translation
i18n: mark merge "upstream" messages for translation
i18n: mark merge CHERRY_PICK_HEAD messages for translation
i18n: mark clone nonexistent repository message for translation
i18n: mark checkout --detach messages for translation
i18n: mark checkout plural warning for translation
builtin/checkout.c | 24 ++++++++++++++++++------
builtin/clone.c | 2 +-
builtin/init-db.c | 12 ++++++------
builtin/merge.c | 16 ++++++++--------
t/t0001-init.sh | 28 ++++++++++++++++++++--------
t/t2020-checkout-detach.sh | 15 ++++++++++++---
t/t5601-clone.sh | 7 +++++--
7 files changed, 70 insertions(+), 34 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] pflash: Restore & fix lazy ROMD switching
From: Jordan Justen @ 2011-04-10 19:33 UTC (permalink / raw)
To: Jan Kiszka; +Cc: qemu-devel, Aurelien Jarno
In-Reply-To: <4DA18C33.6050002@web.de>
On Sun, Apr 10, 2011 at 03:53, Jan Kiszka <jan.kiszka@web.de> wrote:
> Commit 5145b3d1cc revealed a bug in the lazy ROMD switch-back logic, but
> resolved it by breaking that feature. This approach addresses the issue
> by switching back to ROMD after a certain amount of read accesses
> without further unlock sequences.
Without this change, the code will stay in flash mode until a single
read occurs. The code sequence you are wanting to support using will
issue a read before trying to unlock again?
Actually, I suppose it will want to verify the written data before
moving on, so this does make sense.
Is the overhead of switching the modes significant enough to justify
the lazy switch-back? (If so, maybe I'll look at this for cfi01 too.)
Thanks,
-Jordan
^ permalink raw reply
* Re: [RFC PATCH 00/11] Sequencer Foundations
From: Daniel Barkalow @ 2011-04-10 19:33 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Christian Couder, Jonathan Nieder
In-Reply-To: <1302448317-32387-1-git-send-email-artagnon@gmail.com>
On Sun, 10 Apr 2011, Ramkumar Ramachandra wrote:
> Hi,
>
> I've started working on building a sequencer for Git. While the
> outline is described in [1], I'd like some additional clarifications.
> A big thanks to Christian's series [2] for the valuable roadmap.
>
> Please note that 10/11 is not related to this series, but seems to be
> a minor nit that's required to make all existing tests pass.
That looks like an actual bug that only doesn't matter currently because
the function is never called with enough junk on the stack.
> 0. Is the general flow alright?
I suspect it would be easier to review some of this with certain things
squashed together; one patch that changes all of the variable references
to what you want them to be is easier to understand than one that moves
statics to function arguments, one that moves statics to struct fields,
etc. Likewise, when you're converting some of the die() calls to error(),
it's easier to review the patch if all of the die() calls that aren't
changed in that patch don't get changed later in the series.
> 1. Is it okay to use this kind of adaptive error handling (calling
> 'die' in some places and returning error in other places), or should
> it be more uniform?
I think it should be systematic but not necessarily uniform. You should be
able to give a guideline as to how to decide which to use (and you should
probably actually give the guideline, so future developers make consistent
choices). I think of "die" as being ideally for situations where the
program can't understand what has happened well enough to know what to do
about it.
> 2. In 11/11, I've used cmd_revert and cmd_rerere. This is highly
> inelegant, mainly because of the command-line argument parsing
> overhead. Re-implementing it using more low-level functions doesn't
> seem to be the way to go either: for example, 'reset --hard' has some
> additional logic of writing HEAD and ORIG_HEAD, which I don't want to
> duplicate. Should I work on reworking parts of 'rerere.c' and
> 'revert.c', or is there some other way?
(ITYM cmd_reset here)
I think rerere.c should get a rerere_clear(). I think it would make sense
to implement the reset locally; the abort ought to be undoing exactly
those things that you did, and I'm not actually sure the ORIG_HEAD is
entirely appropriate. You ought to be able to use cleanup functions that
correspond to the functions you used to make the mess in the first place.
> 3. From the format of the TODO and DONE files, one more thing should
> be clear- I'm trying to stick to a slight variation of the 'rebase -i'
> format. This part will go into the sequencer. Then I'll use a
> cherry-pick specific file to keep the command-line options. Yes, I'm
> trying to work on Daniel's idea [3] from the very start. Is this a
> good idea?
I certainly like it. :)
> Thanks for reading.
You're welcome. :)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [U-Boot] Please pull u-boot-mpc85xx.git
From: Wolfgang Denk @ 2011-04-10 19:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <alpine.LFD.2.00.1104101120030.23888@right.am.freescale.net>
Dear Kumar Gala,
In message <alpine.LFD.2.00.1104101120030.23888@right.am.freescale.net> you wrote:
> The following changes since commit 4db2fa7f9446d0f2fe8db3d62184b1212fe22707:
>
> Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-04-05 12:24:20 +0200)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-mpc85xx master
>
> Haiying Wang (1):
> powerpc/85xx: Add P1021 specific QE and UEC support
>
> Jiang Yutang (3):
> powerpc/85xx: Enable support for ATI graphics cards on P1022DS
> powerpc/85xx: Add support usb2/etsec and tdm/audio pin multiplex on P1022DS
> powerpc/85xx: Update default hwconfig on P1022DS
>
> Kumar Gala (1):
> powerpc/85xx: Drop CONFIG_VIDEO support on corenet_ds boards
>
> Matthew McClintock (1):
> powerpc/85xx: rename NAND prefixes to CONFIG_SYS
>
> Priyanka Jain (1):
> fsl_esdhc: Deal with watermark level register related changes
>
> Shaohui Xie (1):
> powerpc/85xx: Add PBL boot from SPI flash support on P4080DS
>
> Timur Tabi (2):
> p4080ds: add README.p4080ds which documents the "serdes" hwconfig option
> p4080ds: remove rev1-specific code for the SERDES8 erratum
>
> Zhao Chenhui (2):
> powerpc/85xx: don't init SDRAM when CONFIG_SYS_RAMBOOT
> powerpc/85xx: Add some defines & registers in immap_85xx.h
>
> arch/powerpc/cpu/mpc85xx/cpu.c | 11 +++
> arch/powerpc/cpu/mpc85xx/cpu_init.c | 19 +++++
> arch/powerpc/cpu/mpc85xx/cpu_init_nand.c | 8 +-
> arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c | 106 +++++++++++--------------
> arch/powerpc/cpu/mpc85xx/speed.c | 8 ++-
> arch/powerpc/include/asm/config_mpc85xx.h | 14 +++
> arch/powerpc/include/asm/fsl_ddr_sdram.h | 1 +
> arch/powerpc/include/asm/immap_85xx.h | 53 ++++++++++--
> board/freescale/corenet_ds/tlb.c | 12 +++-
> board/freescale/p1022ds/p1022ds.c | 56 +++++++++++---
> boards.cfg | 1 +
> doc/README.p1022ds | 24 ++++++
> doc/README.p4080ds | 32 ++++++++
> drivers/mmc/fsl_esdhc.c | 8 +-
> drivers/qe/uec.c | 37 +++++++++-
> include/configs/MPC8536DS.h | 18 ++--
> include/configs/MPC8569MDS.h | 12 ++--
> include/configs/MPC8572DS.h | 18 ++--
> include/configs/P1022DS.h | 17 ++++
> include/configs/P1_P2_RDB.h | 12 ++--
> include/configs/P2020DS.h | 14 ++--
> include/configs/corenet_ds.h | 50 ++++++------
> include/fsl_esdhc.h | 15 +++-
> 23 files changed, 394 insertions(+), 152 deletions(-)
> create mode 100644 doc/README.p1022ds
> create mode 100644 doc/README.p4080ds
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Faith: not *wanting* to know what is true." - Friedrich Nietzsche
^ permalink raw reply
* Re: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
From: Alexander Holler @ 2011-04-10 19:29 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Russell King - ARM Linux, Alexander Clouter, linux-kernel,
linux-arm-kernel
In-Reply-To: <4DA1F381.4080003@ahsoftware.de>
On 10.04.2011 20:14, Alexander Holler wrote:
> Hello,
>
> On 09.04.2011 10:29, Bernd Petrovitsch wrote:
>
> Thanks for your helpfull tipps, but I'm writing software since about
> 30a, and I get paid for that since about 25a.
And I'm usingLinux only since I've switched to it from FreeBSD 2.2.
So if anyone else thinks he must send me helpfull insights about free,
open and maintained software, sorry, I've got enough hints in last days
and I will need at least some month to learn to follow them. So please
don't send me more of them. I promise too that I will not send any more
patches until I've learned to follow all the good sugestions.
Thanks to all,
Alexander
^ permalink raw reply
* [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
From: Alexander Holler @ 2011-04-10 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4DA1F381.4080003@ahsoftware.de>
On 10.04.2011 20:14, Alexander Holler wrote:
> Hello,
>
> On 09.04.2011 10:29, Bernd Petrovitsch wrote:
>
> Thanks for your helpfull tipps, but I'm writing software since about
> 30a, and I get paid for that since about 25a.
And I'm usingLinux only since I've switched to it from FreeBSD 2.2.
So if anyone else thinks he must send me helpfull insights about free,
open and maintained software, sorry, I've got enough hints in last days
and I will need at least some month to learn to follow them. So please
don't send me more of them. I promise too that I will not send any more
patches until I've learned to follow all the good sugestions.
Thanks to all,
Alexander
^ permalink raw reply
* [PATCH] Fixing dependencies of ksm_overcommit test
From: Lucas Meneghel Rodrigues @ 2011-04-10 19:27 UTC (permalink / raw)
To: autotest; +Cc: kvm
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
---
client/tests/kvm/tests_base.cfg.sample | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample
index dbd1783..cd8420d 100644
--- a/client/tests/kvm/tests_base.cfg.sample
+++ b/client/tests/kvm/tests_base.cfg.sample
@@ -756,7 +756,7 @@ variants:
type = physical_resources_check
catch_uuid_cmd = dmidecode | awk -F: '/UUID/ {print $2}'
- - ksm_overcommit:
+ - ksm_overcommit: install setup unattended_install.cdrom
only Linux
# Don't preprocess any vms as we need to change its params
vms = ''
--
1.7.4.2
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 01/15] s390x: fix virtio feature bitmap
From: Alexander Graf @ 2011-04-10 19:26 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <20110410192531.GC4551@volta.aurel32.net>
On 10.04.2011, at 21:25, Aurelien Jarno wrote:
> On Mon, Apr 04, 2011 at 04:32:10PM +0200, Alexander Graf wrote:
>> The feature bitmap in the s390 virtio machine is little endian. To
>> address for that, we need to bswap the values after reading them out.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> hw/s390-virtio-bus.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
>> index 58af164..60e0135 100644
>> --- a/hw/s390-virtio-bus.c
>> +++ b/hw/s390-virtio-bus.c
>> @@ -223,7 +223,7 @@ void s390_virtio_device_sync(VirtIOS390Device *dev)
>> cur_offs += num_vq * VIRTIO_VQCONFIG_LEN;
>>
>> /* Sync feature bitmap */
>> - stl_phys(cur_offs, dev->host_features);
>> + stl_phys(cur_offs, bswap32(dev->host_features));
>
> Is bswap32 correct here for both big and little endian guests? I don't
> really understand the reason why a bswap is needed here, especially
> given that AFAIK this code was already used when using KVM.
This is target specific code. The s390-virtio-bus is s390 specific. And yes, the code was also broken with KVM. That's how I first found it actually.
Alex
^ permalink raw reply
* Re: [Xen-users] Issues migrating to xen 4.1 / lvm vg for disk
From: Pasi Kärkkäinen @ 2011-04-10 19:26 UTC (permalink / raw)
To: Sylvain CHEVALIER; +Cc: xen-devel, xen-users
In-Reply-To: <BANLkTikc2VGspO2icP335+e+3vLev9uYgg@mail.gmail.com>
On Sun, Apr 10, 2011 at 12:56:05PM +0800, Sylvain CHEVALIER wrote:
> Hi,
>
> We just migrated xen on gentoo on amd64 from 4.0 to 4.1 and
> encountered a few issues that were not documented. Here is how we
> solved them and what issues are remaining:
>
> 1. Our config files were referring to the LVM devices like
> /dev/vg/domU-root with disk = [ 'phy:vg/domU-root,sda1,w' ]. This does
> not work anymore, we have to include '/dev/': disk = [
> 'phy:/dev/vg/domU-root,sda1,w' ].
>
Hello,
I added xen-devel to CC list.
(I'll reply your other questions on another email.)
-- Pasi
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 02/15] s390x: set alignment for long to 8
From: Aurelien Jarno @ 2011-04-10 19:25 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <1301927544-32767-3-git-send-email-agraf@suse.de>
On Mon, Apr 04, 2011 at 04:32:11PM +0200, Alexander Graf wrote:
> The alignment for longs on s390x is 8. That's the only place where it differs
> from the default alignments found in configure already. The example alignment
> program from Laurent printed the following on a real s390x:
>
> alignof(short) 2
> alignof(int) 4
> alignof(long) 8
> alignof(long long) 8
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> configure | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Thanks, applied.
> diff --git a/configure b/configure
> index faaed60..1e068e6 100755
> --- a/configure
> +++ b/configure
> @@ -3182,6 +3182,7 @@ case "$target_arch2" in
> s390x)
> target_nptl="yes"
> target_phys_bits=64
> + target_long_alignment=8
> ;;
> *)
> echo "Unsupported target CPU"
> --
> 1.6.0.2
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:25 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 15/15] tcg: use ext op for deposit
From: Alexander Graf @ 2011-04-10 19:25 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <20110410192302.GB4551@volta.aurel32.net>
On 10.04.2011, at 21:23, Aurelien Jarno wrote:
> On Tue, Apr 05, 2011 at 09:55:09AM +0200, Alexander Graf wrote:
>>
>> On 05.04.2011, at 06:54, Aurelien Jarno wrote:
>>
>>> On Mon, Apr 04, 2011 at 04:32:24PM +0200, Alexander Graf wrote:
>>>> With the s390x target we use the deposit instruction to store 32bit values
>>>> into 64bit registers without clobbering the upper 32 bits.
>>>>
>>>> This specific operation can be optimized slightly by using the ext operation
>>>> instead of an explicit and in the deposit instruction. This patch adds that
>>>> special case to the generic deposit implementation.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> ---
>>>> tcg/tcg-op.h | 6 +++++-
>>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>>
>>> Have you really measuring a difference here? This should already be
>>> handled, at least on x86, by this code:
>>>
>>> if (TCG_TARGET_REG_BITS == 64) {
>>> if (val == 0xffffffffu) {
>>> tcg_out_ext32u(s, r0, r0);
>>> return;
>>> }
>>> if (val == (uint32_t)val) {
>>> /* AND with no high bits set can use a 32-bit operation. */
>>> rexw = 0;
>>> }
>>> }
>>
>> I've certainly looked at the -d op logs and seen that instead of creating a const tcg variable plus an AND there was now an extu opcode issued, yes. No idea why the case up there didn't trigger.
>>
>
> The question there is looking at -d out_asm. They should be the same at
> the end as the code I pasted above is from tcg/i386/tcg-target.c.
Yes. I was trying to optimize for maximum op length. TCG defines a maximum number of tcg ops to be issued by each target instruction. Since s390 is very CISCy, there are instructions that translate into lots of microops, but are still faster than a C call (register save/restore mostly).
Without this patch, there are some places where we hit that number :).
Alex
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 01/15] s390x: fix virtio feature bitmap
From: Aurelien Jarno @ 2011-04-10 19:25 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <1301927544-32767-2-git-send-email-agraf@suse.de>
On Mon, Apr 04, 2011 at 04:32:10PM +0200, Alexander Graf wrote:
> The feature bitmap in the s390 virtio machine is little endian. To
> address for that, we need to bswap the values after reading them out.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> hw/s390-virtio-bus.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
> index 58af164..60e0135 100644
> --- a/hw/s390-virtio-bus.c
> +++ b/hw/s390-virtio-bus.c
> @@ -223,7 +223,7 @@ void s390_virtio_device_sync(VirtIOS390Device *dev)
> cur_offs += num_vq * VIRTIO_VQCONFIG_LEN;
>
> /* Sync feature bitmap */
> - stl_phys(cur_offs, dev->host_features);
> + stl_phys(cur_offs, bswap32(dev->host_features));
Is bswap32 correct here for both big and little endian guests? I don't
really understand the reason why a bswap is needed here, especially
given that AFAIK this code was already used when using KVM.
> dev->feat_offs = cur_offs + dev->feat_len;
> cur_offs += dev->feat_len * 2;
> @@ -246,7 +246,7 @@ void s390_virtio_device_update_status(VirtIOS390Device *dev)
>
> /* Update guest supported feature bitmap */
>
> - features = ldl_phys(dev->feat_offs);
> + features = bswap32(ldl_phys(dev->feat_offs));
> if (vdev->set_features) {
> vdev->set_features(vdev, features);
> }
> --
> 1.6.0.2
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: Firmware files for Ralink RT28x0
From: Xose Vazquez Perez @ 2011-04-10 19:25 UTC (permalink / raw)
To: users, linux-wireless, ben
Ben Hutchings wrote:
> Ralink provides multiple drivers per bus type for RT28xx and later
> chips. For PCI devices they split between RT2860 and RT309x; for USB
> devices they split between RT2870 and RT307x (I think - the chip model
> numbers don't seem to be stated consistently).
>
> In addition, the USB drivers have two separate images packed together
> and they can select different images based on the controller version:
>
> #ifdef RTMP_MAC_USB
> if ((Version != 0x2860) && (Version != 0x2872) && (Version != 0x3070))
> { // Use Firmware V2.
> //printk("KH:Use New Version,part2\n");
> pFirmwareImage = (PUCHAR)&FirmwareImage[FIRMWAREIMAGEV1_LENGTH];
> FileLength = FIRMWAREIMAGEV2_LENGTH;
> }
> else
> {
> //printk("KH:Use New Version,part1\n");
> pFirmwareImage = FirmwareImage;
> FileLength = FIRMWAREIMAGEV1_LENGTH;
> }
> #endif // RTMP_MAC_USB //
>
> The firmware blobs in RT2870 version 2009-08-20 and RT3070 version
> 2009-05-25 are all marked as version 17 (or 0.17), but *they all have
> different contents*.
>
> I attempted to maintain the same version selection logic when converting
> the staging drivers to use the firmware loader, since I assumed there
> was a good reason for it.
>
As you can see in the ralink web[1] RT28XX/RT30XX USB devices (RT2870/RT2770/RT3572/RT3070)
need _only_ the rt2870.bin fw-file.
And RT28XX/RT30XX PCI/mPCI/PCIe/CardBus devices
(RT2760/RT2790/RT2860/RT2890/RT3060/RT3062/RT3562/RT2860/RT2760/RT2890/RT2790/RT3090)
need _only_ the rt2860.bin fw-file.
> linux-firmware is supposed to have all firmware files referenced by any
> version of Linux
That's a good joke!
linux-firmware is *unmaintained* , a lot of firmwares are missing.
Even the intel ones(microcode.dat, ipw2{1,2}*), zd1211, etc...
Others are very old, really it's a mess.
Fedora puts _forty_ patches on top of linux-firmware.
[1] http://www.ralinktech.com/support.php?s=2
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:25 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:25 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-29 3:51 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:25 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:25 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:24 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:24 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:24 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 19:24 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.