* Re: Here is the tcp-zero-copy patch for kernel 2.6.12-6 .
From: Zach Brown @ 2006-04-05 16:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: yzy, linux-kernel, eeb, green
In-Reply-To: <4433DCAF.5060503@garzik.org>
> 1) Why, we already have zero-copy?
It's poorly named. The sendpage side is so that Lustre's in-kernel
'tcpnal' can get callbacks when an skb tx is completed. I don't know
what the recvpackets thing is for.
It certainly doesn't look like something that will be merged.
(duplicate code, nutty style, questionable double callback registration,
etc)
- z
^ permalink raw reply
* Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)
From: Philippe Gerum @ 2006-04-05 16:45 UTC (permalink / raw)
To: Randy Smith; +Cc: xenomai
In-Reply-To: <4433DC01.6060104@domain.hid>
Randy Smith wrote:
>
>
> Philippe Gerum wrote:
>
>>
>> Ok, just to be 100% sure, I've just tried the following on a stock
>> 2.1.0 grabbed from the mirror:
>>
>> ../somewhere/xenomai-2.1.0/configure --build=i686-linux
>> --host=ppc-linux --prefix=$HOME/xenomai-install CC=ppc_82xx-gcc
>> CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld
>>
>> The resulting tree builds and install fine under $HOME/xenomai-install
>> afterwards. There is no kernel dependency whatsoever since the
>> user-space support does not even know about the kernel version which
>> is going to be used in the first place, so we should be able to get
>> the same user-space setup. Could you try rebuilding in a clean build
>> tree using equivalent switches at config time, and let me know of the
>> outcome? TIA,
>>
> Philippe,
>
> Thanks for your patient help. I did what you asked and it works fine
> for the user side.
>
> The kernel side is what is screwed up. I am using the ELDK 3.1 from the
> DENX CD and when I try applying the Adeos patch, it fails in several
> places. I ended up applying the patch by hand and I only had a few
> places where I was scratching my head as to where to apply the changes
> so that might be what I screwed up. Is the
> xenomai-2.1.0/ksrc/arch/powerpc/patches/adeos-ipipe-2.4.25-ppc-denx-1.0-03.patch
> supposed to apply to the develop tree for ELDK 3.1 instead?? I couldn't
> make heads or tails of the numbering scheme used on the patch wrt the
> "denx-1.0-03" part.
Wrt 2.4 kernels, the project provides patches against snapshots of
Denx's development tree, accessible from
http://www.denx.de/en/Software/CVS. The date of the snapshot was missing
in the patch filenames, which introduced a fair amount of confusion;
this has been fixed in the repository. All 2.4-based Adeos patches for
ppc have been built against Denx's devel tree as of 2005-11-09 so far.
The Adeos version is always given by the trailing rev. number of any
patch filename, e.g. 1.0-04 is the latest Adeos rev. for 2.4/ppc kernels.
For 2.6/ppc kernels, we provide patches against vanilla kernel trees as
released by kernel.org.
> I'm so close...and I really want to figure this out.
>
Ok, it's a bit early for Xmas gifts, but anyway, try this patch on
2.4.25-11 as shipped with the ELDK 3.1:
http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4.25-11-ppc-denx-1.0-04.patch
--
Philippe.
^ permalink raw reply
* Re: Fix ia64 bit ops: Full barriers for bit operations returning
From: Zoltan Menyhart @ 2006-04-05 16:44 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0604031129510.21064@schroedinger.engr.sgi.com>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
Christoph Lameter wrote:
> Could decomplicate this? Just use acquire / release and avoid the
> additional intrinsics. The purpose is first of all correctness. Then we
> can add some whiz bang on top. Also please sent patches inline not as
> attachments.
I could have misunderstood what you wrote yesterday:
>>Could you consider using some cache hints, like "ld8.bias.nta"?
>>"bias" is a hint to acquire exclusive ownership.
>>"nta" is a hint to allocate the cache line only in L2
>>(and side effect: to bias it to be replaced).
>>All of the Itanium 2 processor's atomic instructions are handled
>>exclusively by the L2 cache.
>
> Could you come up with a patch? Currently, I do not seem to be able to
> spend enough time on it.
I thought you had asked for both the correct fencing and the cache hints.
Thanks,
Zoltan
[-- Attachment #2: bitops.diff --]
[-- Type: text/plain, Size: 1717 bytes --]
--- old/include/asm-ia64/bitops.h 2006-04-04 18:19:50.000000000 +0200
+++ linux-2.6.16/include/asm-ia64/bitops.h 2006-04-05 18:38:44.000000000 +0200
@@ -7,6 +7,11 @@
*
* 02/06/02 find_next_bit() and find_first_bit() added from Erich Focht's ia64 O(1)
* scheduler patch
+ * 06/04/05 Added full fencing semantics to the atomic bit operations returning
+ * values.
+ * Note that it is a temporary solution while we are waiting for explicitly
+ * indicated fencing behavior, e.g.:
+ * test_and_set_bit (int nr, void *addr, MODE_BARRIER)
*/
#include <linux/compiler.h>
@@ -160,6 +165,7 @@ test_and_set_bit (int nr, volatile void
volatile __u32 *m;
CMPXCHG_BUGCHECK_DECL
+ ia64_mf();
m = (volatile __u32 *) addr + (nr >> 5);
bit = 1 << (nr & 31);
do {
@@ -192,7 +198,7 @@ __test_and_set_bit (int nr, volatile voi
/**
* test_and_clear_bit - Clear a bit and return its old value
- * @nr: Bit to set
+ * @nr: Bit to clear
* @addr: Address to count from
*
* This operation is atomic and cannot be reordered.
@@ -205,6 +211,7 @@ test_and_clear_bit (int nr, volatile voi
volatile __u32 *m;
CMPXCHG_BUGCHECK_DECL
+ ia64_mf();
m = (volatile __u32 *) addr + (nr >> 5);
mask = ~(1 << (nr & 31));
do {
@@ -237,7 +244,7 @@ __test_and_clear_bit(int nr, volatile vo
/**
* test_and_change_bit - Change a bit and return its old value
- * @nr: Bit to set
+ * @nr: Bit to change
* @addr: Address to count from
*
* This operation is atomic and cannot be reordered.
@@ -250,6 +257,7 @@ test_and_change_bit (int nr, volatile vo
volatile __u32 *m;
CMPXCHG_BUGCHECK_DECL
+ ia64_mf();
m = (volatile __u32 *) addr + (nr >> 5);
bit = (1 << (nr & 31));
do {
^ permalink raw reply
* Throttling NAT interface
From: Casey Scott @ 2006-04-05 16:44 UTC (permalink / raw)
To: netfilter
The gist of what I need to do is restrict the rate of
off-network traffic coming in through a host. The host
is providing basic NAT to an internal network. I have
gotten pretty close to what I need to do with iptables
and tc. The problem is that when an interface is throttle
with tc, the source of the traffic doesn't matter. I don't
want to throttle local traffic, just traffic coming through
the machine from a WAN. The next step was to add another
NIC to the machine. Something like this:
eth0: <local IP1>
eth1: <WAN IP>
eth2: <local IP2>
The problem is that even if traffic destined to be routed
off network comes into eth2, which is throttle via tc, the
return traffic comes back through eth0. Since tc (tbf filter)
just controls the transmitting of an interface, I need to
force the NAT traffic to use eth2. Traffic that is meant to
stay local can use eth0. Is possible to do something like this?
How can I this host to only eth2 for NAT even though both eth0
and eth2 are in the same network? eth0 is not throttled, which
is why local traffic needs to use it.
TIA,
Casey
^ permalink raw reply
* Re: [parisc-linux] Strange newest LAB msg?
From: Joel Soete @ 2006-04-05 16:43 UTC (permalink / raw)
To: deller; +Cc: James.Bottomley, parisc-linux
Hello Helge,
[...]
> If a user then runs on a big iron like N4k he should use a 64bit kernel=
instead, which then would implement your 64bit-changes proposal.
>
Sorry but I misderstood: iirc only 64bit kernel runs on such system like =
A, L,
N class; we haven't the choice?
Thanks,
Joel
PS: btw, I read a lot of your patch related to page size 16k and 64k (for=
pa8000) but not sure we can try it now?=0A=0A----------------------------=
-----------------------------------=0AA free anti-spam and anti-virus fil=
ter on all Scarlet mailboxes=0AMore info on http://www.scarlet.be/
^ permalink raw reply
* [ALSA - lib 0001971]: Some elements incorrectly have capture flags
From: bugtrack @ 2006-04-05 16:42 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1971>
======================================================================
Reported By: pzad
Assigned To:
======================================================================
Project: ALSA - lib
Issue ID: 1971
Category: simple mixer
Reproducibility: always
Severity: minor
Priority: normal
Status: new
======================================================================
Date Submitted: 03-28-2006 12:16 CEST
Last Modified: 04-05-2006 18:42 CEST
======================================================================
Summary: Some elements incorrectly have capture flags
Description:
Some elemnts have capture flags even they have nothing to do with capture.
This will duplicate control in alsamixer - view ALL.
On VIA8233A + ALC650:
Simple mixer control '3D Control - Center',0
Capabilities: volume volume-joined
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 15
Mono: 1 [7%]
Simple mixer control '3D Control - Depth',0
Capabilities: volume volume-joined
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 15
Mono: 0 [0%]
On Audigy 1:
Simple mixer control 'Bass',0
Capabilities: volume
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 40
Front Left: 23 [58%]
Front Right: 23 [58%]
Simple mixer control 'Treble',0
Capabilities: volume
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 40
Front Left: 27 [68%]
Front Right: 27 [68%]
======================================================================
----------------------------------------------------------------------
Raymond - 04-03-06 19:08
----------------------------------------------------------------------
Do the order of the control appear in the alsamixer determined by the name
?
There is no need to place those 3D controls in the front
----------------------------------------------------------------------
Raymond - 04-05-06 18:42
----------------------------------------------------------------------
I can group the lower 4 bands to implement the bass control and the upper 6
bands to implement the treble control.
The new "Bass" and "Treble" will appear in kmix.
how can I add the surround of STAC9708 into kmix ?
/*
Bass control - the lower 4 bands
*/
static int
snd_vortex_bass_treble_info(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_info *uinfo)
{
uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->count = 2;
uinfo->value.integer.min = 0x0000;
uinfo->value.integer.max = 0x7fff;
return 0;
}
static int
snd_vortex_bass_get(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
vortex_t *vortex = snd_kcontrol_chip(kcontrol);
ucontrol->value.integer.value[0] = vortex->bass[0];
ucontrol->value.integer.value[1] = vortex->bass[1];
return 0;
}
static int
snd_vortex_bass_put(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
vortex_t *vortex = snd_kcontrol_chip(kcontrol);
int changed = 0, i;
if ( vortex->bass[0] != ucontrol->value.integer.value[0]) {
vortex->bass[0] = ucontrol->value.integer.value[0];
changed = 1;
};
if ( vortex->bass[1] != ucontrol->value.integer.value[1]) {
vortex->bass[1] = ucontrol->value.integer.value[1];
changed = 1;
};
for (i=0; i<4; i++) {
vortex_Eqlzr_SetLeftGain(vortex, i, vortex->bass[0]);
vortex_Eqlzr_SetRightGain(vortex, i, vortex->bass[1]);
}
return changed;
}
static struct snd_kcontrol_new vortex_bass_kcontrol __devinitdata = {
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.name = "Tone Control - Bass",
.access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
.info = snd_vortex_bass_treble_info,
.get = snd_vortex_bass_get,
.put = snd_vortex_bass_put
};
/*
Treble control - the upper 6 bands
*/
static int
snd_vortex_treble_get(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
vortex_t *vortex = snd_kcontrol_chip(kcontrol);
ucontrol->value.integer.value[0] = vortex->treble[0];
ucontrol->value.integer.value[1] = vortex->treble[1];
return 0;
}
static int
snd_vortex_treble_put(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
vortex_t *vortex = snd_kcontrol_chip(kcontrol);
int changed = 0, i;
if ( vortex->treble[0] != ucontrol->value.integer.value[0]) {
vortex->treble[0] = ucontrol->value.integer.value[0];
changed = 1;
}
if ( vortex->treble[1] != ucontrol->value.integer.value[1]) {
vortex->treble[1] = ucontrol->value.integer.value[1];
changed = 1;
}
for (i=4; i<10; i++) {
vortex_Eqlzr_SetLeftGain(vortex, i, vortex->treble[0]);
vortex_Eqlzr_SetRightGain(vortex, i, vortex->treble[1]);
};
return changed;
}
static struct snd_kcontrol_new vortex_treble_kcontrol __devinitdata = {
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.name = "Tone Control - Treble",
.access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
.info = snd_vortex_bass_treble_info,
.get = snd_vortex_treble_get,
.put = snd_vortex_treble_put
};
Issue History
Date Modified Username Field Change
======================================================================
03-28-06 12:16 pzad New Issue
03-30-06 11:01 Raymond Note Added: 0009028
03-30-06 12:50 pzad Note Added: 0009031
03-30-06 13:13 pzad Note Added: 0009032
03-30-06 13:22 Raymond Note Added: 0009033
03-30-06 13:29 Raymond Note Edited: 0009033
03-30-06 13:41 Raymond Note Edited: 0009033
03-31-06 04:36 Raymond Note Added: 0009041
03-31-06 04:50 Raymond Note Edited: 0009041
04-01-06 01:13 Raymond Note Edited: 0009033
04-03-06 19:08 Raymond Note Added: 0009103
04-05-06 18:42 Raymond Note Added: 0009121
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [ALSA - driver 0002004]: Via say unknown codec on FSC Amilo 1667G
From: bugtrack @ 2006-04-05 16:40 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2004>
======================================================================
Reported By: deathlove23
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 2004
Category: PCI - via82xx
Reproducibility: always
Severity: feature
Priority: normal
Status: new
Distribution: Gentoo
Kernel Version: 2.6.16
======================================================================
Date Submitted: 04-05-2006 18:40 CEST
Last Modified: 04-05-2006 18:40 CEST
======================================================================
Summary: Via say unknown codec on FSC Amilo 1667G
Description:
Hello,
I have a Notebook from FSC: Amilo 1667G
and is get thes messages in boot bzw. on dmesg:
---
ALSA device list:
#0: VIA 8237 with unknown codec at 0xc800, irq 50
---
my Alsa Kernel config is:
---
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_MPU401_UART=y
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_AC97_BUS=y
CONFIG_SND_VIA82XX=y
---
and my lspci -vv is:
---
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: Fujitsu Siemens Computer GmbH Unknown device 1093
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 50
Region 0: I/O ports at c800 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
can you my soundcard to the ID lists eg. another Amilio's?
Thanks
Alex - Deathlove23
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-05-06 18:40 deathlove23 New Issue
04-05-06 18:40 deathlove23 Distribution => Gentoo
04-05-06 18:40 deathlove23 Kernel Version => 2.6.16
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Linux audio driver OMAP5912
From: Michal Szabat @ 2006-04-05 16:38 UTC (permalink / raw)
To: linux-omap-open-source, ruchir.gulati
In-Reply-To: <OFA3EE633B.6C835667-ON65257147.003F99C3-65257147.00403CF6@tcs.com>
----- Original Message -----
From: <ruchir.gulati@tcs.com>
To: <linux-omap-open-source@linux.omap.com>
Sent: Wednesday, April 05, 2006 1:42 PM
Subject: Linux audio driver OMAP5912
>
> Hello,
>
> I am trying to record/capture and play/render audio on the OMAP5912 OSK
> supplied by Spectrum Digital. I am aware of the TLV320AIC23 Audio Codec IC
> present on this board. I want to record and play the audio using the GPP
> or the ARM9 processor, through the MotaVista Linux OS present on the ARM
> processor.
>
> Can anyone please tell me how can I do this? If there is any driver (I
> mean Linux driver for OMAP5912) available for this, then where is it? As
> of now I have searched the OMAP page on the Spectrum Digital webpage and a
> few other websites, but without any success.
>
> If anyone has worked on such a thing, please help with this! Or, if this
> is not possible, please let me know, so that I could take some other
> approach....
>
> Thanks in advance,
> Ruchir Gulati
> Embedded Systems Group,
> TATA Consultancy Services Ltd.
>
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information. If
> you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If you
> have received this communication in error, please notify us by reply
> e-mail or telephone and immediately and permanently delete the message and
> any attachments. Thank you
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
Hello.
I want to compress audio to mp3 or other format, by now without cuccess.
You can check it http://oskfordummies.hp.infoseek.co.jp/howto/audio.html.
----------------------------------------------------------------------
Poznaj Stefana! Zmien komunikator! >>> http://link.interia.pl/f1924
^ permalink raw reply
* [2.6 patch] drivers/parport/share.: unexport parport_get_port
From: Adrian Bunk @ 2006-04-05 16:37 UTC (permalink / raw)
To: philb, tim, andrea; +Cc: linux-parport, linux-kernel
This patch removes the unused EXPORT_SYMBOL(parport_get_port).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc1-mm1-full/drivers/parport/share.c.old 2006-04-05 17:12:05.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/parport/share.c 2006-04-05 17:12:42.000000000 +0200
@@ -1003,7 +1003,6 @@
EXPORT_SYMBOL(parport_unregister_driver);
EXPORT_SYMBOL(parport_register_device);
EXPORT_SYMBOL(parport_unregister_device);
-EXPORT_SYMBOL(parport_get_port);
EXPORT_SYMBOL(parport_put_port);
EXPORT_SYMBOL(parport_find_number);
EXPORT_SYMBOL(parport_find_base);
^ permalink raw reply
* [2.6 patch] drivers/char/random.c: unexport secure_ipv6_port_ephemeral
From: Adrian Bunk @ 2006-04-05 16:36 UTC (permalink / raw)
To: mpm; +Cc: linux-kernel, netdev
This patch removes the unused EXPORT_SYMBOL(secure_ipv6_port_ephemeral).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc1-mm1-full/drivers/char/random.c.old 2006-04-05 17:00:04.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/char/random.c 2006-04-05 17:00:22.000000000 +0200
@@ -1584,7 +1584,6 @@
return twothirdsMD4Transform(daddr, hash);
}
-EXPORT_SYMBOL(secure_ipv6_port_ephemeral);
#endif
#if defined(CONFIG_IP_DCCP) || defined(CONFIG_IP_DCCP_MODULE)
^ permalink raw reply
* Re: : IA64 ISOs based on Fedora Core 5
From: Axel Thimm @ 2006-04-05 16:35 UTC (permalink / raw)
To: linux-ia64
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]
On Wed, Apr 05, 2006 at 10:44:45AM +0100, David Woodhouse wrote:
> On Tue, 2006-04-04 at 22:25 -0400, Paul Nasrat wrote:
> > I assume for the weekly snapshots of rawhide that you'll be putting
> > unique (eg date based) names on the isos so they can be readily
> > identified, else you're going to run into trouble tracking issues
> > across media sets.
>
> To be honest, I'm not convinced that weekly ISO builds are particularly
> useful -- we don't do that for rawhide on other architectures either.
> It's probably better just to encourage people to use rsync to keep up
> with rawhide, rather than downloading it all over again each week.
>
> > Do these isos correspond with FC5 or a random snapshot?
>
> Rawhide for about a week leading up to March 20th was identical to FC5
> in all but the 'fedora-release' package.
>
> If making an IA64 'FC5' I'd be inclined to replace the fedora-release
> package too. In fact, you almost certainly want to do that anyway, since
> you'll be publishing the errata, and fedora-release contains the yum
> configuration.
That might be helpful:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187250
> Aside from the updates, the next task is building Extras and Livna for
> IA64, of course...
and who's going to do ATrpms? ;)
--
Axel.Thimm at ATrpms.net
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Jon Smirl @ 2006-04-05 16:34 UTC (permalink / raw)
To: Al Viro; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <20060405152123.GH27946@ftp.linux.org.uk>
On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > This will break the "color_map" sysfs file for framebuffers -
> > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > for a colormap with 256 entries. In fact, the original patch which
> > changed PAGE_SIZE - 1 to PAGE_SIZE:
>
> ... cheerfully assuming that nobody assumes NUL-termination and
> everyone (sysfs patch writers!) certainly uses the length argument.
> Fscking brilliant, that.
Why does sysfs have two string length determination methods - both
NULL termination and a length parameter. It should be one or the
other, not both. Having both simply cause problems when some
developers implement one scheme and others only implement the other.
>
> Are you willing to audit all sysfs ->show() in the kernel? Original
> author of that turd had not been.
>
> FWIW, "color_map" is a blatant abuse of interface. Doesn't get
> any more borderline...
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [Fastboot] [PATCH] kexec on ia64
From: Khalid Aziz @ 2006-04-05 16:34 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: LKML, Fastboot mailing list, Linux ia64
In-Reply-To: <m1r74d43a9.fsf@ebiederm.dsl.xmission.com>
On Tue, 2006-04-04 at 12:13 -0600, Eric W. Biederman wrote:
> Khalid Aziz <khalid_aziz@hp.com> writes:
> > +void
> > +machine_crash_shutdown(struct pt_regs *pt)
> > +{
> > + /* This function is only called after the system
> > + * has paniced or is otherwise in a critical state.
> > + * The minimum amount of code to allow a kexec'd kernel
> > + * to run successfully needs to happen here.
> > + *
> > + * In practice this means shooting down the other cpus in
> > + * an SMP system.
> > + */
> > + if (in_interrupt()) {
> > + terminate_irqs();
> > + ia64_eoi();
> > + }
> > + system_state = SYSTEM_RESTART;
> > + device_shutdown();
> > + system_state = SYSTEM_BOOTING;
> > + machine_shutdown();
> > +}
>
> machine_crash_shutdown must not call device_shutdown. That has
> been shown to way exceed the minimum necessary to shutdown a system.
> I would prefer this to be a noop stub that doesn't work at all than
> something like this that does way too much, and makes people think
> the code will work.
>
> As for terminate_irqs on x86 we do that on bootup not in the middle
> of a crash shutdown. The apics and xapics are close enough you
> should be able to do the same on ia64.
>
> You display remarkable faith in a kernel that has paniced.
I will look into eliminating this as much as possible.
> Having machine_shutdown only build when you have PCI present
> and then not making KEXEC depend on PCI is wrong.
>
> The #ifdef needs to move inside machine_shutdown.
Fixed.
>
> > +
> > +/*
> > + * Do not allocate memory (or fail in any way) in machine_kexec().
> > + * We are past the point of no return, committed to rebooting now.
> > + */
> > +void machine_kexec(struct kimage *image)
> > +{
> > + unsigned long indirection_page;
> > + relocate_new_kernel_t rnk;
> > + unsigned long pta, impl_va_bits;
> > + void *pal_addr = efi_get_pal_addr();
> > + unsigned long code_addr = (unsigned
> > long)page_address(image->control_code_page);
> > +
> > +#ifdef CONFIG_HOTPLUG_CPU
> > + int cpu;
> > +
> > + for_each_online_cpu(cpu) {
> > + if (cpu != smp_processor_id())
> > + cpu_down(cpu);
> > + }
> > +#elif CONFIG_SMP
> > + smp_call_function(kexec_stop_this_cpu, (void *)image->start, 0, 0);
> > +#endif
>
> This CPU and HOTPUG_CPU stuff belongs in machine shutdown.
Moved to machine_shutdown().
>
> > +
> > + ia64_set_itv(1<<16);
> > + /* Interrupts aren't acceptable while we reboot */
> > + local_irq_disable();
> > +
> > + /* set kr0 to the appropriate address */
> > + set_io_base();
> > +
> > + /* Disable VHPT */
> > + impl_va_bits = ffz(~(local_cpu_data->unimpl_va_mask | (7UL << 61)));
> > + pta = POW2(61) - POW2(vmlpt_bits);
> > + ia64_set_pta(pta | (0 << 8) | (vmlpt_bits << 2) | 0);
> > +
> > +#ifdef CONFIG_IA64_HP_ZX1
> > + ioc_iova_disable();
> > +#endif
>
> This also looks like it needs to be part of machine_shutdown.
> I have no confidence in ioc_iova_disable when the machine is crashing.
> Basically anything that touches a pointer is likely to be bad.
I have moved above code to machine_shutdown. I would prefer to delay
disabling VHPT as much as possible, but since machine_kexec gets called
soon after machine_shutdown and we should be executing kernel code
strictly at this point which uses pinned TR entries, disabling VHPT
should not have any deleterious effect.
>
> > + /* now execute the control code.
> > + * We will start by executing the control code linked into the
> > + * kernel as opposed to the code we copied in control code buffer * page. When
> > this code switches to physical mode, we will start
> > + * executing the code in control code buffer page. Reason for
> > + * doing this is we start code execution in virtual address space.
> > + * If we were to try to execute the newly copied code in virtual
> > + * address space, we will need to make an ITLB entry to avoid ITLB
> > + * miss. By executing the code linked into kernel, we take advantage
> > + * of the ITLB entry already in place for kernel and avoid making
> > + * a new entry.
> > + */
> > + indirection_page = image->head & PAGE_MASK;
> > +
> > + rnk = (relocate_new_kernel_t)&code_addr;
> > + (*rnk)(indirection_page, image->start, ia64_boot_param,
> > + GRANULEROUNDDOWN((unsigned long) pal_addr));
> > + BUG();
> > + for (;;)
> > + ;
> > +}
>
>
> Eric
Thanks for the review.
--
Khalid
====================================================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
^ permalink raw reply
* Re: [Fastboot] [PATCH] kexec on ia64
From: Khalid Aziz @ 2006-04-05 16:34 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: LKML, Fastboot mailing list, Linux ia64
In-Reply-To: <m1r74d43a9.fsf@ebiederm.dsl.xmission.com>
On Tue, 2006-04-04 at 12:13 -0600, Eric W. Biederman wrote:
> Khalid Aziz <khalid_aziz@hp.com> writes:
> > +void
> > +machine_crash_shutdown(struct pt_regs *pt)
> > +{
> > + /* This function is only called after the system
> > + * has paniced or is otherwise in a critical state.
> > + * The minimum amount of code to allow a kexec'd kernel
> > + * to run successfully needs to happen here.
> > + *
> > + * In practice this means shooting down the other cpus in
> > + * an SMP system.
> > + */
> > + if (in_interrupt()) {
> > + terminate_irqs();
> > + ia64_eoi();
> > + }
> > + system_state = SYSTEM_RESTART;
> > + device_shutdown();
> > + system_state = SYSTEM_BOOTING;
> > + machine_shutdown();
> > +}
>
> machine_crash_shutdown must not call device_shutdown. That has
> been shown to way exceed the minimum necessary to shutdown a system.
> I would prefer this to be a noop stub that doesn't work at all than
> something like this that does way too much, and makes people think
> the code will work.
>
> As for terminate_irqs on x86 we do that on bootup not in the middle
> of a crash shutdown. The apics and xapics are close enough you
> should be able to do the same on ia64.
>
> You display remarkable faith in a kernel that has paniced.
I will look into eliminating this as much as possible.
> Having machine_shutdown only build when you have PCI present
> and then not making KEXEC depend on PCI is wrong.
>
> The #ifdef needs to move inside machine_shutdown.
Fixed.
>
> > +
> > +/*
> > + * Do not allocate memory (or fail in any way) in machine_kexec().
> > + * We are past the point of no return, committed to rebooting now.
> > + */
> > +void machine_kexec(struct kimage *image)
> > +{
> > + unsigned long indirection_page;
> > + relocate_new_kernel_t rnk;
> > + unsigned long pta, impl_va_bits;
> > + void *pal_addr = efi_get_pal_addr();
> > + unsigned long code_addr = (unsigned
> > long)page_address(image->control_code_page);
> > +
> > +#ifdef CONFIG_HOTPLUG_CPU
> > + int cpu;
> > +
> > + for_each_online_cpu(cpu) {
> > + if (cpu != smp_processor_id())
> > + cpu_down(cpu);
> > + }
> > +#elif CONFIG_SMP
> > + smp_call_function(kexec_stop_this_cpu, (void *)image->start, 0, 0);
> > +#endif
>
> This CPU and HOTPUG_CPU stuff belongs in machine shutdown.
Moved to machine_shutdown().
>
> > +
> > + ia64_set_itv(1<<16);
> > + /* Interrupts aren't acceptable while we reboot */
> > + local_irq_disable();
> > +
> > + /* set kr0 to the appropriate address */
> > + set_io_base();
> > +
> > + /* Disable VHPT */
> > + impl_va_bits = ffz(~(local_cpu_data->unimpl_va_mask | (7UL << 61)));
> > + pta = POW2(61) - POW2(vmlpt_bits);
> > + ia64_set_pta(pta | (0 << 8) | (vmlpt_bits << 2) | 0);
> > +
> > +#ifdef CONFIG_IA64_HP_ZX1
> > + ioc_iova_disable();
> > +#endif
>
> This also looks like it needs to be part of machine_shutdown.
> I have no confidence in ioc_iova_disable when the machine is crashing.
> Basically anything that touches a pointer is likely to be bad.
I have moved above code to machine_shutdown. I would prefer to delay
disabling VHPT as much as possible, but since machine_kexec gets called
soon after machine_shutdown and we should be executing kernel code
strictly at this point which uses pinned TR entries, disabling VHPT
should not have any deleterious effect.
>
> > + /* now execute the control code.
> > + * We will start by executing the control code linked into the
> > + * kernel as opposed to the code we copied in control code buffer * page. When
> > this code switches to physical mode, we will start
> > + * executing the code in control code buffer page. Reason for
> > + * doing this is we start code execution in virtual address space.
> > + * If we were to try to execute the newly copied code in virtual
> > + * address space, we will need to make an ITLB entry to avoid ITLB
> > + * miss. By executing the code linked into kernel, we take advantage
> > + * of the ITLB entry already in place for kernel and avoid making
> > + * a new entry.
> > + */
> > + indirection_page = image->head & PAGE_MASK;
> > +
> > + rnk = (relocate_new_kernel_t)&code_addr;
> > + (*rnk)(indirection_page, image->start, ia64_boot_param,
> > + GRANULEROUNDDOWN((unsigned long) pal_addr));
> > + BUG();
> > + for (;;)
> > + ;
> > +}
>
>
> Eric
Thanks for the review.
--
Khalid
==================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
^ permalink raw reply
* [2.6 patch] ISDN_DRV_GIGASET should select, not depend on CRC_CCITT
From: Adrian Bunk @ 2006-04-05 16:32 UTC (permalink / raw)
To: hjlipp, tilman; +Cc: gigaset307x-common, kkeil, isdn4linux, linux-kernel
CRC_CCITT is an internal helper function that should be select'ed.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc1-mm1-full/drivers/isdn/gigaset/Kconfig.old 2006-04-05 17:42:54.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/isdn/gigaset/Kconfig 2006-04-05 17:43:07.000000000 +0200
@@ -3,7 +3,8 @@
config ISDN_DRV_GIGASET
tristate "Siemens Gigaset support (isdn)"
- depends on ISDN_I4L && CRC_CCITT
+ depends on ISDN_I4L
+ select CRC_CCITT
help
Say m here if you have a Gigaset or Sinus isdn device.
^ permalink raw reply
* RE: Compiling xenoprof
From: Santos, Jose Renato G @ 2006-04-05 16:30 UTC (permalink / raw)
To: David Carr; +Cc: xen-devel
David,
You are not able to run oprofile on domU only.
The current model supported for XenOProfile is system-wide
profiling, i.e. profiling multiple domains, using the same
hardware counters. In this model
Dom0 has to be the coordinator of a profiling session.
You have to first start oprofile daemon in dom0 indicating which
domains are participating in the profiling session. Then you
need to run "opcontrol --start" in each domU, and finally
start profiling from dom0 (opcontrol --start).
Look at the user guide in http://xenoprof.sourceforge.net
for more details
Renato
>> -----Original Message-----
>> From: David Carr [mailto:dc@dcarr.org]
>> Sent: Wednesday, April 05, 2006 9:20 AM
>> To: Santos, Jose Renato G
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Compiling xenoprof
>>
>> Renato,
>>
>> Thanks for your reply. The steps below got the kernels to
>> build. I'm not sure that everything is quite right yet
>> though. I can profile on domain 0 and also run opcontrol
>> --reset on the guests. However running "opcontrol --start"
>> on the guests results in:
>>
>> Using default event: GLOBAL_POWER_EVENTS:100000:1:1:1 Failed
>> to open profile device: Operation not permitted Using 2.6+
>> OProfile kernel interface.
>>
>> Couldn't start oprofiled.
>> Check the log file "/var/lib/oprofile/oprofiled.log" and
>> kernel syslog
>>
>> It appears that this error is coming daemon/liblegacy/init.c
>> or daemon/init.c This error only occurs on the guests (which
>> are using the dom0 kernel).
>> opcontrol --start suceeds on dom0.
>>
>> Any ideas?
>>
>> Thanks again,
>> David Carr
>>
>> Install steps:
>>
>> In Xen 3.0.0 source directory:
>>
>> patch -p1 < xenoprof-2.0-xen-3.0.0.patch patch -p1 <
>> xenoprof-2.0-linux-2.6-sparse.patch
>> make kernels
>>
>> This will ultimately fail. Then do:
>>
>> In linux-2.6.12-xen0 directory:
>>
>> patch -p2 < xenoprof-2.0-linux-2.6.12.patch make kernels
>>
>> This will ultimately fail. Then do:
>>
>> In linux-2.6.12-xenU directory:
>>
>> patch -p2 < xenoprof-2.0-linux-2.6.12.patch make kernels
>>
>> This will succeed. Then do:
>>
>> make dist
>> sudo make install
>>
>>
>> In oprofile source directory:
>>
>> patch -p1 < oprofile-0.9.1-xen.patch
>>
>>
>> Install oprofile normally
>>
>>
>> Santos, Jose Renato G wrote:
>>
>> >
>> >David,
>> >
>> >You are right. This is not very clean.
>> >Yes, you need to do a "make" to create the xen0 and xenU
>> trees before
>> >applying the patch in step c).
>> >If you configure the kernel with oprofile support (CONFIG_OPROFILE)
>> >before step c) you will probably get a compilation error
>> when you run
>> >make since the patch was not applied yet. You could either delay
>> >setting (CONFIG_OPROFILE) for after you apply patch "c" or you can
>> >apply the patch after you get the compilation error, and
>> then run make
>> >again.
>> >
>> >It would be better if there was a "make" option to create
>> the xen0/xenU
>> >trees without compiling them. Does anybody know if there is such an
>> >option? I remember looking for it in the Makefile and not
>> finding it,
>> >but this was a while ago.
>> >
>> >We are now working on getting the xenoprof code included in
>> >xen-unstable.
>> >This should make life much easier for those wanting to use oprofile.
>> >
>> >Renato
>> >
>> >
>> >
>> >>>-----Original Message-----
>> >>>From: xen-devel-bounces@lists.xensource.com
>> >>>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of David
>> >>>Carr
>> >>>Sent: Tuesday, April 04, 2006 7:31 PM
>> >>>To: xen-devel@lists.xensource.com
>> >>>Subject: [Xen-devel] Compiling xenoprof
>> >>>
>> >>>I'm having some trouble compiling Xen 3.0.0 with the xenoprof
>> >>>patches.
>> >>>
>> >>>The xenoprof instructions say:
>> >>>
>> >>> In order to run OProfile in Xen environments four patches are
>> >>>needed:
>> >>> a) xenoprof-2.0-xen-3.0.0.patch
>> >>> Patch for Xen hypervisor.
>> >>> b) xenoprof-2.0-linux-2.6-sparse.patch
>> >>> Patch for Xenolinux. Contains oprofile architecture specific
>> >>>driver
>> >>> for xen (Apply to linux-sparse tree in Xen source tree)
>> >>> c) xenoprof-2.0-linux-2.6.12.patch
>> >>> Patch for oprofile kernel module in linux 2.6.12.
>> >>>Contain modifications
>> >>> to generic oprofile driver code to support xen.
>> (Apply twice,
>> >>>once to
>> >>> dom0 and once to domU trees)
>> >>>
>> >>>
>> >>>Every thing goes fine until part c. The linux-2.6.12-xen0 and
>> >>>linux-2.6.12-xenU directories are empty until you build xen (and
>> >>>therefore can't be patched yet.) Doing a make world will
>> populate
>> >>>these trees but also compiles everything.
>> >>>
>> >>>What is the proper sequence of patching and make commands
>> to build a
>> >>>xenoprof tree?
>> >>>
>> >>>Thanks,
>> >>>David Carr
>> >>>
>> >>>
>> >>>
>> >>>_______________________________________________
>> >>>Xen-devel mailing list
>> >>>Xen-devel@lists.xensource.com
>> >>>http://lists.xensource.com/xen-devel
>> >>>
>> >>>
>> >>>
>>
>>
^ permalink raw reply
* Re: unresolved symbols for drm module on sparc64
From: Adrian Bunk @ 2006-04-05 16:30 UTC (permalink / raw)
To: Per Øyvind Karlsen; +Cc: linux-kernel
In-Reply-To: <200604051530.00883.peroyvind@sintrax.net>
On Wed, Apr 05, 2006 at 03:30:00PM +0200, Per Øyvind Karlsen wrote:
> When building 2.6.17-rc1 on sparc64 I run into this problem:
> if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map
> -b /root/RPM/BUILD/kernel-linus-2.6/temp-root -r 2.6.17-rc1.16mdksmp; fi
> WARNING: /root/RPM/BUILD/kernel-linus-2.6/temp-root/lib/modules/2.6.17-rc1.16mdksmp/kernel/drivers/char/drm/drm.ko
> needs unknown symbol dma_alloc_coherent
> WARNING: /root/RPM/BUILD/kernel-linus-2.6/temp-root/lib/modules/2.6.17-rc1.16mdksmp/kernel/drivers/char/drm/drm.ko
> needs unknown symbol dma_free_coherent
> make: *** [_modinst_post] Error 1
>
> I'm not subscribed to the list, just thought that I should report since it
> recently broke, so CC me if any more info is needed.
> I'm also attaching my .config in case it might be of help:)
>...
Thanks for your report.
This is a known bug, and a fix is available at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/2.6.17-rc1-mm1/broken-out/drm_pci-needs-dma-mappingh.patch
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [Lhms-devel] [RFC 0/6] Swapless Page Migration V1: Overview
From: Christoph Lameter @ 2006-04-05 16:28 UTC (permalink / raw)
To: Lee Schermerhorn
Cc: linux-mm, lhms-devel, Hirokazu Takahashi, Marcelo Tosatti,
KAMEZAWA Hiroyuki
In-Reply-To: <1144248362.5203.22.camel@localhost.localdomain>
On Wed, 5 Apr 2006, Lee Schermerhorn wrote:
> Does this approach still allow "migrate-on-fault" for anon pages?
I am not aware of something that would be in the way.
> Especially, in the case where the migrating page has >1 pte referencing
> it? How will the fault handler find all of the pte's referencing the
> old page? Actually, I don't think we'd want to burden the task whose
The fault handler can find these via the reverse maps.
> fault caused the migration with finding and replacing and replacing all
> pte's referecing the old page. Using a real cache, this isn't a problem
> because we replace the old page with a new one in the cache, and the
> cache ptes reference the cache entry. Tasks are free to fault in a real
> pte for the new page at any time. I'd hate to lose this capability. I
> believe that this is one of the reasons that Marcello used a real idr-
> based cache for the migration cache.
We never allow a faulting in of the new page before migration is
complete. The replacing of the swap ptes with real ptes was always done
after migration was complete. Same thing here.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: FAQ entry for loopback mounting
From: David Woodhouse @ 2006-04-05 16:27 UTC (permalink / raw)
To: Ralph Siemsen; +Cc: linux-mtd
In-Reply-To: <4433E9A1.1030807@netwinder.org>
On Wed, 2006-04-05 at 12:00 -0400, Ralph Siemsen wrote:
> Here the "128ki" is the erase block size. Only "ki" is accepted, due to
> bugs in the parsing code. The code understands "M" and "G" but will
> barf on subsequent arguments. You cannot add the logical-seeming "B",
> for example, "128kiB" is not accepted. If you use no letters, then the
> value is interpreted in BYTES (unlike the mtdram which assumes kiB).
You probably wouldn't want 'M' or 'G' on their own, because those would
be multiples of ten, and unlikely to be useful in this context. Making
it accept (and ignore) 'B' would perhaps be useful -- patches welcome.
--
dwmw2
^ permalink raw reply
* [U-Boot-Users] [PATCH] objcopy for srec and bin files should be done on .o files
From: Martin Hicks @ 2006-04-05 16:26 UTC (permalink / raw)
To: u-boot
The Makefile rule for creating srec and bin files fails for me frequently.
I believe that we should be doing the ojbcopy on the .o files, not the ELF
binary.
Signed-off-by: Martin Hicks <mort@bork.org>
---
examples/Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
35b9e5c91127f1428c6e207fe2bca76782ca5b36
diff --git a/examples/Makefile b/examples/Makefile
index 2f8c4c4..36fe2a3 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -123,10 +123,10 @@ $(LIB): .depend $(LIBOBJS)
$(LD) -g $(EX_LDFLAGS) -Ttext $(LOAD_ADDR) \
-o $@ -e $(<:.o=) $< $(LIB) \
-L$(gcclibdir) -lgcc
-%.srec: %
+%.srec: %.o
$(OBJCOPY) -O srec $< $@ 2>/dev/null
-%.bin: %
+%.bin: %.o
$(OBJCOPY) -O binary $< $@ 2>/dev/null
#########################################################################
--
1.2.4
--
Martin Hicks || mort at bork.org || PGP/GnuPG: 0x4C7F2BEE
^ permalink raw reply related
* Re: How should I handle binary file with GIT
From: Nicolas Pitre @ 2006-04-05 16:25 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Randal L. Schwartz, Jakub Narebski, git
In-Reply-To: <20060405155528.GI14625@spearce.org>
On Wed, 5 Apr 2006, Shawn Pearce wrote:
> The clearly safe approach is to include the full SHA1 ID of the
> old object the patch was created from and use the xdelta in the
> patch only as a means of transporting a compressed form of the new
> version of the object. If git-diff starts to export say a base 64
> encoding of the xdelta then it should also include the full SHA1
> ID for binary files, even if --full-index wasn't given.
>
> git-apply should only apply an xdelta patch to the exact same
> old object. If the tree currently has a different object at that
> path then reject the patch entirely.
Amen. Exactly what I just said.
Nicolas
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Nicolas Pitre @ 2006-04-05 16:21 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Jakub Narebski, git
In-Reply-To: <86wte4rq3d.fsf@blue.stonehenge.com>
On Wed, 5 Apr 2006, Randal L. Schwartz wrote:
> >>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
>
> >> IIRC bsdiff is used by Firefox to distribute binary software updates.
> >> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
> >> supposedly offers worse compression (bigger diffs).
>
> Nicolas> We already have our own delta code for pack storage.
>
> I think the issue is related to being able to cherry-pick and merge
> when binaries are involved. I've been worried about that myself.
> How well are binaries supported these days for all the operations
> we're taking for granted? When is a "diff" expected to be a real
> "diff" and not just "binary files differ"?
First of all, does cherry-picking binary patches is a sensible thing to
do?
Do you expect, say, a Word document, a JPEG image, or an MP3 file to
still be valid and error free if two binary patches modifying a
different part of the same file (same revision) are successively
applied? I seriously doubt it.
And what do you do with conflicts? Using diff3 might be sensible for
text data, but for binaries you really need a tool that understands the
type of data your binary contains, which means one tool for each
possible type of binary data which is outside the scope of GIT.
For example, if you patch a .wav file adding some data, then you end up
with the additional samples and a new length in the file header. If
another patch to that .wav is applied, then it is easy to find the
"surrounding context" where the second patch is adding/removing some
other samples, but then you really needs knowledge about the .wav format
to handle the conflict that will occur on the .wav header modification.
And so on for all possible binary types.
So IMHO a binary patch format is only useful for easy _transport_ along
with other text patches. And the binary patch must either apply
perfectly against the same source file or it must not apply at all.
That's the only sensible accommodation we can do with a generic binary
patch format.
When the patch doesn't apply to your tree, then nothing prevents you
from hooking a dedicated tool that will pick up the original file, the
reconstructed remote version according to the binary patch you received
and your own modified version so that tool can process them and do the
necessary changes with proper knowledge of the data format.
Nicolas
^ permalink raw reply
* Re: bad tcp checksum
From: Tom Eastep @ 2006-04-05 16:20 UTC (permalink / raw)
To: netfilter
In-Reply-To: <4433E766.9080409@denouden.info>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Wednesday 05 April 2006 08:51, Jan den Ouden (ml) wrote:
> Hi,
>
> I'm seeing a strange problem with kernel 2.6.12 Xen domain0 with all
> netfilter options compiled in. I'm trying to do port forwarding to an
> internal machine from an internet gateway box.
>
> What works ok is forwarding from gateway:143 to internalmachine:143.
>
> But when I forward from gateway:1000 to internalmachine:143 I get bad
> TCP checksums on the return packets. These packets are ignored on the
> client machine on the external internet.
>
I suggest that you search the Xen-users list archives -- this issue has been
discussed ad nauseum.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Can't mount /dev/md0 after stopping a synchronization
From: Tuomas Leikola @ 2006-04-05 16:20 UTC (permalink / raw)
To: Mike Garey; +Cc: linux-raid
In-Reply-To: <c79e949d0604050839k2287fefdm53f6abb08dfcae89@mail.gmail.com>
On 4/5/06, Mike Garey <random51k@gmail.com> wrote:
> I tried booting from /dev/hdc1 (as /dev/md0 in grub) using a 2.6.15
> kernel with md and raid1 support built in and this is what I now get:
>
> md: autodetecting raid arrays
> md: autorun ...
> md: considering hdc1 ...
> md: adding hdc1 ...
> md: created md0
> md: bind:<hdc1>
> raid1: RAID set md0 active with 1 out of 2 mirrors
> md: ...autrun done.
>
> Warning: unable to open an initial console
> Input: AT translated set 2 keyboard as /class/input/input0
>
> and then at this point, the system just hangs and nothing happens. So
> I seem to be getting closer.. If I try booting from a kernel without
> raid1 and md support, but using an initrd with raid1/md modules, then
> I get the "ALERT! /dev/md0 does not exist. Dropping to a shell!"
> message. I can't understand why there would be any difference between
> using a kernel with raid1/md support, or using an initrd image with
> raid1/md support, but apparently there is. If anyone else has any
> suggestions, please keep them coming.
Sounds like your initrd could use a command like
mdadm --assemble /dev/md0 /dev/hda1 /dev/hdc1
at some point before mounting the real rootfs. There are many cleaner
examples in the list archive, but that should do the trick. It seems
like your initrd-kernel doesn't autostart the raid for some reason
(config option?).
Note, you should never do any read/write access to the component disks
after creating the raid. I guess you know this already, but some
wording seemed suspect.
Can you specify more what is the problem with mounting md0? The log
snipped doesn't show any errors about that.
^ permalink raw reply
* help. a question on "make menuconfig"
From: Ming Liu @ 2006-04-05 16:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am a novice for embendded linux. My platform is Xilinx Virtex4 (PPC405).
I have downloaded the kernal source of linuxppc_2_4_devel and modified the
Makefile as:
ARCH := ppc
CROSS_COMPILE = powerpc-405-linux-gnu-
But when I execute "make menuconfig", the following error happens,
mingliu@linux:~/linuxppc_2_4_devel> make menuconfig
make: *** arch/ppc: Is a directory. Stop.
mingliu@linux:~/linuxppc_2_4_devel>
Why this error happened? Is there something wrong with the Makefile? I did
nothing except for specifying the ARCH and the CROSS_COMPILE.
Thanks for your help.
BR
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ 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.