[TCP]: Unconditionally clear TCP_NAGLE_PUSH in skb_entail().
tree d017e5c04afcd33d99a2bf8554332c5754df8c36 parent 0fbbeb1ba43bd04f0f1d4f161b7f72437a1c8a03 author David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:13:06 -0700 committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:13:06 -0700 [TCP]: Unconditionally clear TCP_NAGLE_PUSH in skb_entail(). Intention of this bit is to force pushing of the existing send queue when TCP_CORK or TCP_NODELAY state changes via setsockopt(). But it's easy to create a situation where the bit never clears. For example, if the send queue starts empty: 1) set TCP_NODELAY 2) clear TCP_NODELAY 3) set TCP_CORK 4) do small write() The current code will leave TCP_NAGLE_PUSH set after that sequence. Unconditionally clearing the bit when new data is added via skb_entail() solves the problem. Signed-off-by: David S. Miller [EMAIL PROTECTED] net/ipv4/tcp.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -584,7 +584,7 @@ static inline void skb_entail(struct soc sk_charge_skb(sk, skb); if (!sk-sk_send_head) sk-sk_send_head = skb; - else if (tp-nonagleTCP_NAGLE_PUSH) + if (tp-nonagle TCP_NAGLE_PUSH) tp-nonagle = ~TCP_NAGLE_PUSH; } - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET]: Fix socket bitop damage
tree 117e7f530fa2aa37751cfd22908cd81253fd08f8
parent 66a79a19a7c582efd99bb143c3a59fbda006eb39
author Ralf Baechle [EMAIL PROTECTED] Wed, 24 Aug 2005 00:11:30 -0700
committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:11:30 -0700
[NET]: Fix socket bitop damage
The socket flag cleanups that went into 2.6.12-rc1 are basically oring
the flags of an old socket into the socket just being created.
Unfortunately that one was just initialized by sock_init_data(), so already
has SOCK_ZAPPED set. As the result zapped sockets are created and all
incoming connection will fail due to this bug which again was carefully
replicated to at least AX.25, NET/ROM or ROSE.
In order to keep the abstraction alive I've introduced sock_copy_flags()
to copy the socket flags from one sockets to another and used that
instead of the bitwise copy thing. Anyway, the idea here has probably
been to copy all flags, so sock_copy_flags() should be the right thing.
With this the ham radio protocols are usable again, so I hope this will
make it into 2.6.13.
Signed-off-by: Ralf Baechle DL5RB [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
include/net/sock.h |5 +
net/ax25/af_ax25.c |7 +--
net/netrom/af_netrom.c |7 +--
net/rose/af_rose.c |7 +--
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -384,6 +384,11 @@ enum sock_flags {
SOCK_QUEUE_SHRUNK, /* write queue has been shrunk recently */
};
+static inline void sock_copy_flags(struct sock *nsk, struct sock *osk)
+{
+ nsk-sk_flags = osk-sk_flags;
+}
+
static inline void sock_set_flag(struct sock *sk, enum sock_flags flag)
{
__set_bit(flag, sk-sk_flags);
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -875,12 +875,7 @@ struct sock *ax25_make_new(struct sock *
sk-sk_sndbuf = osk-sk_sndbuf;
sk-sk_state= TCP_ESTABLISHED;
sk-sk_sleep= osk-sk_sleep;
-
- if (sock_flag(osk, SOCK_DBG))
- sock_set_flag(sk, SOCK_DBG);
-
- if (sock_flag(osk, SOCK_ZAPPED))
- sock_set_flag(sk, SOCK_ZAPPED);
+ sock_copy_flags(sk, osk);
oax25 = ax25_sk(osk);
diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -459,12 +459,7 @@ static struct sock *nr_make_new(struct s
sk-sk_sndbuf = osk-sk_sndbuf;
sk-sk_state= TCP_ESTABLISHED;
sk-sk_sleep= osk-sk_sleep;
-
- if (sock_flag(osk, SOCK_ZAPPED))
- sock_set_flag(sk, SOCK_ZAPPED);
-
- if (sock_flag(osk, SOCK_DBG))
- sock_set_flag(sk, SOCK_DBG);
+ sock_copy_flags(sk, osk);
skb_queue_head_init(nr-ack_queue);
skb_queue_head_init(nr-reseq_queue);
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -556,12 +556,7 @@ static struct sock *rose_make_new(struct
sk-sk_sndbuf = osk-sk_sndbuf;
sk-sk_state= TCP_ESTABLISHED;
sk-sk_sleep= osk-sk_sleep;
-
- if (sock_flag(osk, SOCK_ZAPPED))
- sock_set_flag(sk, SOCK_ZAPPED);
-
- if (sock_flag(osk, SOCK_DBG))
- sock_set_flag(sk, SOCK_DBG);
+ sock_copy_flags(sk, osk);
init_timer(rose-timer);
init_timer(rose-idletimer);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NETFILTER]: Fix HW checksum handling in ip_queue/ip6_queue
tree 615163e271e256063ede49f73ae01e8abb39ed72
parent 1344a41637114485fac7afa1505bce2ff862807a
author Patrick McHardy [EMAIL PROTECTED] Wed, 24 Aug 2005 00:10:35 -0700
committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:10:35 -0700
[NETFILTER]: Fix HW checksum handling in ip_queue/ip6_queue
The checksum needs to be filled in on output, after mangling a packet
ip_summed needs to be reset.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
net/ipv4/netfilter/ip_queue.c |7 +++
net/ipv6/netfilter/ip6_queue.c |7 +++
2 files changed, 14 insertions(+)
diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c
--- a/net/ipv4/netfilter/ip_queue.c
+++ b/net/ipv4/netfilter/ip_queue.c
@@ -214,6 +214,12 @@ ipq_build_packet_message(struct ipq_queu
break;
case IPQ_COPY_PACKET:
+ if (entry-skb-ip_summed == CHECKSUM_HW
+ (*errp = skb_checksum_help(entry-skb,
+ entry-info-outdev == NULL))) {
+ read_unlock_bh(queue_lock);
+ return NULL;
+ }
if (copy_range == 0 || copy_range entry-skb-len)
data_len = entry-skb-len;
else
@@ -385,6 +391,7 @@ ipq_mangle_ipv4(ipq_verdict_msg_t *v, st
if (!skb_ip_make_writable(e-skb, v-data_len))
return -ENOMEM;
memcpy(e-skb-data, v-payload, v-data_len);
+ e-skb-ip_summed = CHECKSUM_NONE;
e-skb-nfcache |= NFC_ALTERED;
/*
diff --git a/net/ipv6/netfilter/ip6_queue.c b/net/ipv6/netfilter/ip6_queue.c
--- a/net/ipv6/netfilter/ip6_queue.c
+++ b/net/ipv6/netfilter/ip6_queue.c
@@ -211,6 +211,12 @@ ipq_build_packet_message(struct ipq_queu
break;
case IPQ_COPY_PACKET:
+ if (entry-skb-ip_summed == CHECKSUM_HW
+ (*errp = skb_checksum_help(entry-skb,
+ entry-info-outdev == NULL))) {
+ read_unlock_bh(queue_lock);
+ return NULL;
+ }
if (copy_range == 0 || copy_range entry-skb-len)
data_len = entry-skb-len;
else
@@ -381,6 +387,7 @@ ipq_mangle_ipv6(ipq_verdict_msg_t *v, st
if (!skb_ip_make_writable(e-skb, v-data_len))
return -ENOMEM;
memcpy(e-skb-data, v-payload, v-data_len);
+ e-skb-ip_summed = CHECKSUM_NONE;
e-skb-nfcache |= NFC_ALTERED;
/*
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RPC]: Kill bogus kmap in krb5
tree 61c7cde232f4d241489fba3bd5386ceaefd223ac parent 14869c388673e8db3348ab3706fa6485d0f0cf95 author Herbert Xu [EMAIL PROTECTED] Wed, 24 Aug 2005 00:09:53 -0700 committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:09:53 -0700 [RPC]: Kill bogus kmap in krb5 While I was going through the crypto users recently, I noticed this bogus kmap in sunrpc. It's totally unnecessary since the crypto layer will do its own kmap before touching the data. Besides, the kmap is throwing the return value away. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] net/sunrpc/auth_gss/gss_krb5_crypto.c |2 -- 1 files changed, 2 deletions(-) diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c --- a/net/sunrpc/auth_gss/gss_krb5_crypto.c +++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c @@ -185,9 +185,7 @@ make_checksum(s32 cksumtype, char *heade sg-page = body-pages[i]; sg-offset = offset; sg-length = thislen; - kmap(sg-page); /* XXX kmap_atomic? */ crypto_digest_update(tfm, sg, 1); - kunmap(sg-page); len -= thislen; i++; offset = 0; - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[TCP]: Do TSO deferral even if tail SKB can go out now.
tree fa5de8895166ae31371264544027941d469044f9
parent f6fdd7d9c273bb2a20ab467cb57067494f932fa3
author Dmitry Yusupov [EMAIL PROTECTED] Wed, 24 Aug 2005 00:09:27 -0700
committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:09:27 -0700
[TCP]: Do TSO deferral even if tail SKB can go out now.
If the tail SKB fits into the window, it is still
benefitical to defer until the goal percentage of
the window is available. This give the application
time to feed more data into the send queue and thus
results in larger TSO frames going out.
Patch from Dmitry Yusupov [EMAIL PROTECTED].
Signed-off-by: David S. Miller [EMAIL PROTECTED]
net/ipv4/tcp_output.c |4
1 files changed, 4 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -925,10 +925,6 @@ static int tcp_tso_should_defer(struct s
limit = min(send_win, cong_win);
- /* If sk_send_head can be sent fully now, just do it. */
- if (skb-len = limit)
- return 0;
-
if (sysctl_tcp_tso_win_divisor) {
u32 chunk = min(tp-snd_wnd, tp-snd_cwnd * tp-mss_cache);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[IA64] remove unused function __ia64_get_io_port_base
tree d5a2b5ef9687fd67b9897825e8011f458cb29515
parent 4aec0fb12267718c750475f3404337ad13caa8f5
author Tony Luck [EMAIL PROTECTED] Fri, 19 Aug 2005 04:40:00 -0700
committer Tony Luck [EMAIL PROTECTED] Fri, 19 Aug 2005 04:40:00 -0700
[IA64] remove unused function __ia64_get_io_port_base
Not only was this unused, but its somewhat eccentric declaration
of static inline const unsigned long gives gcc4 heartburn.
Signed-off-by: Tony Luck [EMAIL PROTECTED]
include/asm-ia64/io.h |8
1 files changed, 8 deletions(-)
diff --git a/include/asm-ia64/io.h b/include/asm-ia64/io.h
--- a/include/asm-ia64/io.h
+++ b/include/asm-ia64/io.h
@@ -120,14 +120,6 @@ static inline void ___ia64_mmiowb(void)
ia64_mfa();
}
-static inline const unsigned long
-__ia64_get_io_port_base (void)
-{
- extern unsigned long ia64_iobase;
-
- return ia64_iobase;
-}
-
static inline void*
__ia64_mk_io_addr (unsigned long port)
{
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPV4]: Fix negative timer loop with lots of ipv4 peers.
tree cf8f84bee2b6e23a17e97beef53791a698256f77 parent c3a20692ca5c8eb8cf5d0f489d4fc839ce7593d1 author Dave Johnson [EMAIL PROTECTED] Wed, 24 Aug 2005 00:10:15 -0700 committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:10:15 -0700 [IPV4]: Fix negative timer loop with lots of ipv4 peers. From: Dave Johnson [EMAIL PROTECTED] Found this bug while doing some scaling testing that created 500K inet peers. peer_check_expire() in net/ipv4/inetpeer.c isn't using inet_peer_gc_mintime correctly and will end up creating an expire timer with less than the minimum duration, and even zero/negative if enough active peers are present. If 65K peers, the timer will be less than inet_peer_gc_mintime, and with 70K peers, the timer duration will reach zero and go negative. The timer handler will continue to schedule another zero/negative timer in a loop until peers can be aged. This can continue for at least a few minutes or even longer if the peers remain active due to arriving packets while the loop is occurring. Bug is present in both 2.4 and 2.6. Same patch will apply to both just fine. Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] net/ipv4/inetpeer.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c --- a/net/ipv4/inetpeer.c +++ b/net/ipv4/inetpeer.c @@ -450,10 +450,13 @@ static void peer_check_expire(unsigned l /* Trigger the timer after inet_peer_gc_mintime .. inet_peer_gc_maxtime * interval depending on the total number of entries (more entries, * less interval). */ - peer_periodic_timer.expires = jiffies - + inet_peer_gc_maxtime - - (inet_peer_gc_maxtime - inet_peer_gc_mintime) / HZ * - peer_total / inet_peer_threshold * HZ; + if (peer_total = inet_peer_threshold) + peer_periodic_timer.expires = jiffies + inet_peer_gc_mintime; + else + peer_periodic_timer.expires = jiffies + + inet_peer_gc_maxtime + - (inet_peer_gc_maxtime - inet_peer_gc_mintime) / HZ * + peer_total / inet_peer_threshold * HZ; add_timer(peer_periodic_timer); } - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[AX25]: UID fixes
tree ee4f22a33557bae4883eb2f4fb1359e97ac74186
parent 53b924b31fa53ac3007df3fef6870d5074a9adf8
author Ralf Baechle [EMAIL PROTECTED] Wed, 24 Aug 2005 00:11:45 -0700
committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:11:45 -0700
[AX25]: UID fixes
o Brown paperbag bug - ax25_findbyuid() was always returning a NULL pointer
as the result. Breaks ROSE completly and AX.25 if UID policy set to deny.
o While the list structure of AX.25's UID to callsign mapping table was
properly protected by a spinlock, it's elements were not refcounted
resulting in a race between removal and usage of an element.
Signed-off-by: Ralf Baechle DL5RB [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
include/net/ax25.h | 18 +-
net/ax25/af_ax25.c | 20 +++
net/ax25/ax25_route.c | 12 ---
net/ax25/ax25_uid.c| 83 +
net/netrom/af_netrom.c | 24 +-
net/rose/af_rose.c | 20 +++
6 files changed, 100 insertions(+), 77 deletions(-)
diff --git a/include/net/ax25.h b/include/net/ax25.h
--- a/include/net/ax25.h
+++ b/include/net/ax25.h
@@ -139,11 +139,25 @@ enum {
#define AX25_DEF_DS_TIMEOUT(3 * 60 * HZ) /* DAMA timeout 3
minutes */
typedef struct ax25_uid_assoc {
- struct ax25_uid_assoc *next;
+ struct hlist_node uid_node;
+ atomic_trefcount;
uid_t uid;
ax25_addresscall;
} ax25_uid_assoc;
+#define ax25_uid_for_each(__ax25, node, list) \
+ hlist_for_each_entry(__ax25, node, list, uid_node)
+
+#define ax25_uid_hold(ax25) \
+ atomic_inc(((ax25)-refcount))
+
+static inline void ax25_uid_put(ax25_uid_assoc *assoc)
+{
+ if (atomic_dec_and_test(assoc-refcount)) {
+ kfree(assoc);
+ }
+}
+
typedef struct {
ax25_addresscalls[AX25_MAX_DIGIS];
unsigned char repeated[AX25_MAX_DIGIS];
@@ -376,7 +390,7 @@ extern unsigned long ax25_display_timer(
/* ax25_uid.c */
extern int ax25_uid_policy;
-extern ax25_address *ax25_findbyuid(uid_t);
+extern ax25_uid_assoc *ax25_findbyuid(uid_t);
extern int ax25_uid_ioctl(int, struct sockaddr_ax25 *);
extern struct file_operations ax25_uid_fops;
extern void ax25_uid_free(void);
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1002,7 +1002,8 @@ static int ax25_bind(struct socket *sock
struct sock *sk = sock-sk;
struct full_sockaddr_ax25 *addr = (struct full_sockaddr_ax25 *)uaddr;
ax25_dev *ax25_dev = NULL;
- ax25_address *call;
+ ax25_uid_assoc *user;
+ ax25_address call;
ax25_cb *ax25;
int err = 0;
@@ -1021,9 +1022,15 @@ static int ax25_bind(struct socket *sock
if (addr-fsa_ax25.sax25_family != AF_AX25)
return -EINVAL;
- call = ax25_findbyuid(current-euid);
- if (call == NULL ax25_uid_policy !capable(CAP_NET_ADMIN)) {
- return -EACCES;
+ user = ax25_findbyuid(current-euid);
+ if (user) {
+ call = user-call;
+ ax25_uid_put(user);
+ } else {
+ if (ax25_uid_policy !capable(CAP_NET_ADMIN))
+ return -EACCES;
+
+ call = addr-fsa_ax25.sax25_call;
}
lock_sock(sk);
@@ -1034,10 +1041,7 @@ static int ax25_bind(struct socket *sock
goto out;
}
- if (call == NULL)
- ax25-source_addr = addr-fsa_ax25.sax25_call;
- else
- ax25-source_addr = *call;
+ ax25-source_addr = call;
/*
* User already set interface with SO_BINDTODEVICE
diff --git a/net/ax25/ax25_route.c b/net/ax25/ax25_route.c
--- a/net/ax25/ax25_route.c
+++ b/net/ax25/ax25_route.c
@@ -422,8 +422,8 @@ static inline void ax25_adjust_path(ax25
*/
int ax25_rt_autobind(ax25_cb *ax25, ax25_address *addr)
{
+ ax25_uid_assoc *user;
ax25_route *ax25_rt;
- ax25_address *call;
int err;
if ((ax25_rt = ax25_get_route(addr, NULL)) == NULL)
@@ -434,16 +434,18 @@ int ax25_rt_autobind(ax25_cb *ax25, ax25
goto put;
}
- if ((call = ax25_findbyuid(current-euid)) == NULL) {
+ user = ax25_findbyuid(current-euid);
+ if (user) {
+ ax25-source_addr = user-call;
+ ax25_uid_put(user);
+ } else {
if (ax25_uid_policy !capable(CAP_NET_BIND_SERVICE)) {
err = -EPERM;
goto put;
}
- call = (ax25_address *)ax25-ax25_dev-dev-dev_addr;
+ ax25-source_addr = *(ax25_address
*)ax25-ax25_dev-dev-dev_addr;
}
- ax25-source_addr = *call;
-
if (ax25_rt-digipeat != NULL) {
if ((ax25-digipeat = kmalloc(sizeof(ax25_digi), GFP_ATOMIC))
==
[PKT_SCHED]: Fix missing qdisc_destroy() in qdisc_create_dflt()
tree 80aff375f2b1de10a69743d73977df39f356dda5 parent d2287f844187158e5eddd0d5de8e95bd607abcb7 author Thomas Graf [EMAIL PROTECTED] Wed, 24 Aug 2005 00:12:44 -0700 committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:12:44 -0700 [PKT_SCHED]: Fix missing qdisc_destroy() in qdisc_create_dflt() qdisc_create_dflt() is missing to destroy the newly allocated default qdisc if the initialization fails resulting in leaks of all kinds. The only caller in mainline which may trigger this bug is sch_tbf.c in tbf_create_dflt_qdisc(). Note: qdisc_create_dflt() doesn't fulfill the official locking requirements of qdisc_destroy() but since the qdisc could never be seen by the outside world this doesn't matter and it can stay as-is until the locking of pkt_sched is cleaned up. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] net/sched/sch_generic.c |1 + 1 files changed, 1 insertion(+) diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -438,6 +438,7 @@ struct Qdisc * qdisc_create_dflt(struct if (!ops-init || ops-init(sch, NULL) == 0) return sch; + qdisc_destroy(sch); errout: return NULL; } - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[IA64] Fix simulator boot (for real this time).
tree 868c53b157ceacf5be84004f9ecc464b794256c2 parent 62d75f3753647656323b0365faa43fc1a8f7be97 author Peter Chubb [EMAIL PROTECTED] Tue, 23 Aug 2005 07:50:00 -0700 committer Tony Luck [EMAIL PROTECTED] Tue, 23 Aug 2005 21:41:56 -0700 [IA64] Fix simulator boot (for real this time). Thanks to Stephane, we've now worked out the real cause of the `Linux will not boot on simulator' problem. Turns out it's a stack overflow because the stack pointer wasn't being initialised properly in boot_head.S (it was being initialised to the lowest instead of the highest address of the stack, so the first push started to overwrite data in the BSS). Signed-off-by: Peter Chubb [EMAIL PROTECTED] Signed-off-by: Tony Luck [EMAIL PROTECTED] arch/ia64/hp/sim/boot/boot_head.S |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/hp/sim/boot/boot_head.S b/arch/ia64/hp/sim/boot/boot_head.S --- a/arch/ia64/hp/sim/boot/boot_head.S +++ b/arch/ia64/hp/sim/boot/boot_head.S @@ -22,7 +22,7 @@ GLOBAL_ENTRY(_start) .save rp, r0 .body movl gp = __gp - movl sp = stack_mem + movl sp = stack_mem+16384-16 bsw.1 br.call.sptk.many rp=start_bootloader END(_start) - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ROSE]: Fix missing unlocks in rose_route_frame()
tree 0f1dcf6e5f9f57989d0aca1a565fa56701ed7556
parent d5d283751ef3c05b6766501a46800cbee84959d6
author David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:50:09 -0700
committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 00:50:09 -0700
[ROSE]: Fix missing unlocks in rose_route_frame()
Noticed by Coverity checker.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
net/rose/rose_route.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -994,8 +994,10 @@ int rose_route_frame(struct sk_buff *skb
* 1. The frame isn't for us,
* 2. It isn't owned by any existing route.
*/
- if (frametype != ROSE_CALL_REQUEST) /* XXX */
- return 0;
+ if (frametype != ROSE_CALL_REQUEST) { /* XXX */
+ ret = 0;
+ goto out;
+ }
len = (((skb-data[3] 4) 0x0F) + 1) / 2;
len += (((skb-data[3] 0) 0x0F) + 1) / 2;
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (alpha NUMA)
tree 2309d142ab9b80c64172d3cad43bb2420086d9d2 parent 81065e2f415af6c028eac13f481fb9e60a0b487b author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:44:50 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:39 -0700 [PATCH] Kconfig fix (alpha NUMA) NUMA is broken on alpha; marked as such Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/alpha/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -522,7 +522,7 @@ source mm/Kconfig config NUMA bool NUMA Support (EXPERIMENTAL) - depends on DISCONTIGMEM + depends on DISCONTIGMEM BROKEN help Say Y to compile the kernel to support NUMA (Non-Uniform Memory Access). This option is for configuring high-end multiprocessor - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (ISA_DMA_API and sound/*)
tree 5fb22ae8b2ef903d27850f7894ed669fabce96ad parent e9bcb173dd1747075214a1ccdb65dc6320cae49d author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:45:06 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:40 -0700 [PATCH] Kconfig fix (ISA_DMA_API and sound/*) fixed kconfig dependencies on ISA_DMA_API for parts of sound/* that rely on it. Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] include/sound/core.h |2 ++ sound/Kconfig|2 +- sound/core/Makefile |2 +- sound/core/sound.c |2 +- sound/isa/Kconfig|2 +- sound/oss/Kconfig|6 +++--- sound/pci/Kconfig|2 +- 7 files changed, 10 insertions(+), 8 deletions(-) diff --git a/include/sound/core.h b/include/sound/core.h --- a/include/sound/core.h +++ b/include/sound/core.h @@ -360,11 +360,13 @@ int snd_device_free_all(snd_card_t *card /* isadma.c */ +#ifdef CONFIG_ISA_DMA_API #define DMA_MODE_NO_ENABLE 0x0100 void snd_dma_program(unsigned long dma, unsigned long addr, unsigned int size, unsigned short mode); void snd_dma_disable(unsigned long dma); unsigned int snd_dma_pointer(unsigned long dma, unsigned int size); +#endif /* misc.c */ diff --git a/sound/Kconfig b/sound/Kconfig --- a/sound/Kconfig +++ b/sound/Kconfig @@ -77,7 +77,7 @@ source sound/parisc/Kconfig endmenu menu Open Sound System - depends on SOUND!=n (BROKEN || (!SPARC32 !SPARC64)) + depends on SOUND!=n config SOUND_PRIME tristate Open Sound System (DEPRECATED) diff --git a/sound/core/Makefile b/sound/core/Makefile --- a/sound/core/Makefile +++ b/sound/core/Makefile @@ -5,7 +5,7 @@ snd-objs := sound.o init.o memory.o info.o control.o misc.o \ device.o wrappers.o -ifeq ($(CONFIG_ISA),y) +ifeq ($(CONFIG_ISA_DMA_API),y) snd-objs += isadma.o endif ifeq ($(CONFIG_SND_OSSEMUL),y) diff --git a/sound/core/sound.c b/sound/core/sound.c --- a/sound/core/sound.c +++ b/sound/core/sound.c @@ -432,7 +432,7 @@ EXPORT_SYMBOL(snd_device_new); EXPORT_SYMBOL(snd_device_register); EXPORT_SYMBOL(snd_device_free); /* isadma.c */ -#ifdef CONFIG_ISA +#ifdef CONFIG_ISA_DMA_API EXPORT_SYMBOL(snd_dma_program); EXPORT_SYMBOL(snd_dma_disable); EXPORT_SYMBOL(snd_dma_pointer); diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig --- a/sound/isa/Kconfig +++ b/sound/isa/Kconfig @@ -1,7 +1,7 @@ # ALSA ISA drivers menu ISA devices - depends on SND!=n ISA + depends on SND!=n ISA ISA_DMA_API config SND_AD1848_LIB tristate diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -80,7 +80,7 @@ config SOUND_EMU10K1 config MIDI_EMU10K1 bool Creative SBLive! MIDI (EXPERIMENTAL) - depends on SOUND_EMU10K1 EXPERIMENTAL + depends on SOUND_EMU10K1 EXPERIMENTAL ISA_DMA_API help Say Y if you want to be able to use the OSS /dev/sequencer interface. This code is still experimental. @@ -503,7 +503,7 @@ config SOUND_VIA82CXXX config MIDI_VIA82CXXX bool VIA 82C686 MIDI - depends on SOUND_VIA82CXXX + depends on SOUND_VIA82CXXX ISA_DMA_API help Answer Y to use the MIDI interface of the Via686. You may need to enable this in the BIOS before it will work. This is for connection @@ -512,7 +512,7 @@ config MIDI_VIA82CXXX config SOUND_OSS tristate OSS sound modules - depends on SOUND_PRIME + depends on SOUND_PRIME ISA_DMA_API help OSS is the Open Sound System suite of sound card drivers. They make sound programming easier since they provide a common API. Say Y or diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig --- a/sound/pci/Kconfig +++ b/sound/pci/Kconfig @@ -314,7 +314,7 @@ config SND_YMFPCI config SND_ALS4000 tristate Avance Logic ALS4000 - depends on SND + depends on SND ISA_DMA_API select SND_OPL3_LIB select SND_MPU401_UART select SND_PCM - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (epca on 64bit)
tree f6ca23abfd0777f7e3c571efbd58b67af3eaf1e8 parent ac6babd26ce514e0017ec5809051ea6cdc44c8f6 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:45:01 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:39 -0700 [PATCH] Kconfig fix (epca on 64bit) epca is broken on 64bit; marked as such Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/char/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -138,7 +138,7 @@ config CYZ_INTR config DIGIEPCA tristate Digiboard Intelligent Async Support - depends on SERIAL_NONSTANDARD BROKEN_ON_SMP + depends on SERIAL_NONSTANDARD BROKEN_ON_SMP (!64BIT || BROKEN) ---help--- This is a driver for Digi International's Xx, Xeve, and Xem series of cards which provide multiple serial ports. You would need - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
libata: release prep (bump versions, etc.)
tree c1960e7a0fa37330b6e8ad9ba228ea31a97d22c7
parent f6fdd7d9c273bb2a20ab467cb57067494f932fa3
author Jeff Garzik [EMAIL PROTECTED] Tue, 23 Aug 2005 10:53:51 -0400
committer Jeff Garzik [EMAIL PROTECTED] Tue, 23 Aug 2005 10:53:51 -0400
libata: release prep (bump versions, etc.)
- bump versions where necessary
- remove two duplicated+outdated doc comments
- add MODULE_VERSION() to AHCI driver
drivers/scsi/ahci.c |1 +
drivers/scsi/ata_piix.c |2 +-
drivers/scsi/libata-core.c | 25 -
drivers/scsi/libata.h |2 +-
drivers/scsi/sata_promise.c |2 +-
5 files changed, 4 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -1105,6 +1105,7 @@ MODULE_AUTHOR(Jeff Garzik);
MODULE_DESCRIPTION(AHCI SATA low-level driver);
MODULE_LICENSE(GPL);
MODULE_DEVICE_TABLE(pci, ahci_pci_tbl);
+MODULE_VERSION(DRV_VERSION);
module_init(ahci_init);
module_exit(ahci_exit);
diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c
--- a/drivers/scsi/ata_piix.c
+++ b/drivers/scsi/ata_piix.c
@@ -32,7 +32,7 @@
#include linux/libata.h
#define DRV_NAME ata_piix
-#define DRV_VERSION1.03
+#define DRV_VERSION1.04
enum {
PIIX_IOCFG = 0x54, /* IDE I/O configuration register */
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -2268,19 +2268,6 @@ void ata_qc_prep(struct ata_queued_cmd *
* spin_lock_irqsave(host_set lock)
*/
-
-
-/**
- * ata_sg_init_one - Prepare a one-entry scatter-gather list.
- * @qc: Queued command
- * @buf: transfer buffer
- * @buflen: length of buf
- *
- * Builds a single-entry scatter-gather list to initiate a
- * transfer utilizing the specified buffer.
- *
- * LOCKING:
- */
void ata_sg_init_one(struct ata_queued_cmd *qc, void *buf, unsigned int buflen)
{
struct scatterlist *sg;
@@ -2312,18 +2299,6 @@ void ata_sg_init_one(struct ata_queued_c
* spin_lock_irqsave(host_set lock)
*/
-
-/**
- * ata_sg_init - Assign a scatter gather list to a queued command
- * @qc: Queued command
- * @sg: Scatter-gather list
- * @n_elem: length of sg list
- *
- * Attaches a scatter-gather list to a queued command.
- *
- * LOCKING:
- */
-
void ata_sg_init(struct ata_queued_cmd *qc, struct scatterlist *sg,
unsigned int n_elem)
{
diff --git a/drivers/scsi/libata.h b/drivers/scsi/libata.h
--- a/drivers/scsi/libata.h
+++ b/drivers/scsi/libata.h
@@ -26,7 +26,7 @@
#define __LIBATA_H__
#define DRV_NAME libata
-#define DRV_VERSION1.11 /* must be exactly four chars */
+#define DRV_VERSION1.12 /* must be exactly four chars */
struct ata_scsi_args {
u16 *id;
diff --git a/drivers/scsi/sata_promise.c b/drivers/scsi/sata_promise.c
--- a/drivers/scsi/sata_promise.c
+++ b/drivers/scsi/sata_promise.c
@@ -40,7 +40,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION1.01
+#define DRV_VERSION1.02
enum {
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (arv)
tree f5fdcf5dd425fc6df501971ac2575360d7c37c05 parent a2b2f45be7e9138bde7fcba3b8e9257fea04d087 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:45:46 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:41 -0700 [PATCH] Kconfig fix (arv) arv uses constants provided only by include/asm-m32r/m32700ut/m32700ut_lan.h It won't build for any subarchitecture other than M32700UT; marked as such. Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/media/video/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -356,7 +356,7 @@ config VIDEO_M32R_AR config VIDEO_M32R_AR_M64278 tristate Use Colour AR module M64278(VGA) - depends on VIDEO_M32R_AR + depends on VIDEO_M32R_AR PLAT_M32700UT ---help--- Say Y here to use the Renesas M64278E-800 camera module, which supports VGA(640x480 pixcels) size of images. - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (airo_cs on m32r)
tree 2fd70a093445ca3a0806141ca6d8fa4f926b1861 parent a4d544fdd30111a1183ab92ea25febb8b6460214 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:45:56 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:41 -0700 [PATCH] Kconfig fix (airo_cs on m32r) airo_cs is broken on m32r; marked as such. [Proper fix would involve separating PCI-dependent parts and making sure they don't get in the way _and_ arranging for asm/scatterlist.h getting picked on m32r] Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/net/wireless/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -270,7 +270,7 @@ config PCMCIA_HERMES config AIRO_CS tristate Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards - depends on NET_RADIO PCMCIA + depends on NET_RADIO PCMCIA (BROKEN || !M32R) ---help--- This is the standard Linux driver to support Cisco/Aironet PCMCIA 802.11 wireless cards. This driver is the same as the Aironet - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (M32R_PLDSIO dependecies)
tree a0b910b7e369ec580065a74c45ddcdc0fc8c5904 parent 14d891d20374c139acfaa379e61a7091b00df8fa author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:46:06 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:42 -0700 [PATCH] Kconfig fix (M32R_PLDSIO dependecies) M32R_PLDSIO depends on subarchitecture providing PLD_ESIO0CR and friends. Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/serial/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -819,7 +819,7 @@ config SERIAL_M32R_SIO_CONSOLE config SERIAL_M32R_PLDSIO bool M32R SIO I/F on a PLD - depends on SERIAL_M32R_SIO=y + depends on SERIAL_M32R_SIO=y (PLAT_OPSPUT || PALT_USRV || PLAT_M32700UT) default n help Say Y here if you want to use the M32R serial controller - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (ppc32 SMP dependencies)
tree b7d5afe6cf1ada72f18c0207e830d8387274d6f3 parent 51583cf108b27baf81c6db3ec718f932314986ea author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:46:26 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:42 -0700 [PATCH] Kconfig fix (ppc32 SMP dependencies) ppc SMP is supported only for 6xx/POWER3/POWER4 - i.e. ones that have PPC_STD_MMU. Dependency fixed. Signed-off-by: Al Viro [EMAIL PROTECTED] Acked-by: Paul Mackerras [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/ppc/Kconfig |1 + 1 files changed, 1 insertion(+) diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -911,6 +911,7 @@ config PPCBUG_NVRAM default y if PPC_PREP config SMP + depends on PPC_STD_MMU bool Symmetric multi-processing support ---help--- This enables support for systems with more than one CPU. If you have - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (ppc 4xx and early serial)
tree 909650e573cccf7d497953cbdf97a76b9423bcf1 parent c4457fb9010765620faebccf4daf83b288295154 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:46:36 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:43 -0700 [PATCH] Kconfig fix (ppc 4xx and early serial) a bunch of ppc 4xx variants unconditionally calls early_serial_setup() and therefore needs SERIAL_8250 Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/ppc/platforms/4xx/Kconfig | 10 ++ 1 files changed, 10 insertions(+) diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig --- a/arch/ppc/platforms/4xx/Kconfig +++ b/arch/ppc/platforms/4xx/Kconfig @@ -3,6 +3,11 @@ config 4xx depends on 40x || 44x default y +config WANT_EARLY_SERIAL + bool + select SERIAL_8250 + default n + menu IBM 4xx options depends on 4xx @@ -18,6 +23,7 @@ config ASH config BUBINGA bool Bubinga + select WANT_EARLY_SERIAL help This option enables support for the IBM 405EP evaluation board. @@ -70,21 +76,25 @@ choice config BAMBOO bool Bamboo + select WANT_EARLY_SERIAL help This option enables support for the IBM PPC440EP evaluation board. config EBONY bool Ebony + select WANT_EARLY_SERIAL help This option enables support for the IBM PPC440GP evaluation board. config LUAN bool Luan + select WANT_EARLY_SERIAL help This option enables support for the IBM PPC440SP evaluation board. config OCOTEA bool Ocotea + select WANT_EARLY_SERIAL help This option enables support for the IBM PPC440GX evaluation board. - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (CONFIG_PM on 44x)
tree 8940b518f5bc72bd05722873829884e1ab8f9dc8 parent f08243a491f3e21feabbb04476a03fb0cbc975ff author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:46:41 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:43 -0700 [PATCH] Kconfig fix (CONFIG_PM on 44x) CONFIG_PM is broken on 44x; removed duplicate entry for CONFIG_PM, made the inclusion of generic one conditional on BROKEN || !44x. Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/ppc/Kconfig |2 ++ arch/ppc/platforms/4xx/Kconfig |4 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -1122,7 +1122,9 @@ config PROC_HARDWARE source drivers/zorro/Kconfig +if !44x || BROKEN source kernel/power/Kconfig +endif config SECCOMP bool Enable seccomp to safely compute untrusted bytecode diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig --- a/arch/ppc/platforms/4xx/Kconfig +++ b/arch/ppc/platforms/4xx/Kconfig @@ -240,10 +240,6 @@ config PPC_GEN550 depends on 4xx default y -config PM - bool Power Management support (EXPERIMENTAL) - depends on 4xx EXPERIMENTAL - choice prompt TTYS0 device and default console depends on 40x - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (emac dependencient)
tree 55f4012ba6a1216c5eed29f59b25c321731a46f9 parent 6299afc40c8612a87358ecea80882395fe67111f author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:46:46 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:43 -0700 [PATCH] Kconfig fix (emac dependencient) emac doesn't build modular; ibm_emac_debug doesn't build at all (missing headers). Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/net/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1145,7 +1145,7 @@ config IBMVETH be called ibmveth. config IBM_EMAC - tristate IBM PPC4xx EMAC driver support + bool IBM PPC4xx EMAC driver support depends on 4xx select CRC32 ---help--- @@ -1154,7 +1154,7 @@ config IBM_EMAC config IBM_EMAC_ERRMSG bool Verbose error messages - depends on IBM_EMAC + depends on IBM_EMAC BROKEN config IBM_EMAC_RXB int Number of receive buffers - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (sparc32 drivers/char dependencies)
tree 893f6c381087588c69bd0694c69fe66d33898538 parent 997183dc2a8992374d93e66f5ea0d58fa1022a47 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:46:51 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:43 -0700 [PATCH] Kconfig fix (sparc32 drivers/char dependencies) since sparc32 Kconfig includes drivers/char/Kconfig (instead of duplicating its parts) we need several new dependencies there to exclude the stuff broken on sparc32 and not excluded by existing dependencies. Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/char/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -80,7 +80,7 @@ config SERIAL_NONSTANDARD config COMPUTONE tristate Computone IntelliPort Plus serial support - depends on SERIAL_NONSTANDARD BROKEN_ON_SMP + depends on SERIAL_NONSTANDARD BROKEN_ON_SMP (BROKEN || !SPARC32) ---help--- This driver supports the entire family of Intelliport II/Plus controllers with the exception of the MicroChannel controllers and @@ -208,7 +208,7 @@ config SYNCLINK config SYNCLINKMP tristate SyncLink Multiport support - depends on SERIAL_NONSTANDARD + depends on SERIAL_NONSTANDARD (BROKEN || !SPARC32) help Enable support for the SyncLink Multiport (2 or 4 ports) serial adapter, running asynchronous and HDLC communications up @@ -735,7 +735,7 @@ config SGI_IP27_RTC config GEN_RTC tristate Generic /dev/rtc emulation - depends on RTC!=y !IA64 !ARM !PPC64 !M32R + depends on RTC!=y !IA64 !ARM !PPC64 !M32R !SPARC32 ---help--- If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod (man mknod), you - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] alpha gcc4 warnings
tree f1dfed1a990b8dec1269b88350b6c837973ccadc
parent a238b563502a7f458624b9c6404742e441b2f9e8
author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:46:56 +0100
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:43 -0700
[PATCH] alpha gcc4 warnings
on UP smp_call_function() is expanded to expression. Alpha oprofile
calls that puppy and ignores the return value. And has -Werror for
arch/*...
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
arch/alpha/oprofile/common.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/alpha/oprofile/common.c b/arch/alpha/oprofile/common.c
--- a/arch/alpha/oprofile/common.c
+++ b/arch/alpha/oprofile/common.c
@@ -65,7 +65,7 @@ op_axp_setup(void)
model-reg_setup(reg, ctr, sys);
/* Configure the registers on all cpus. */
- smp_call_function(model-cpu_setup, reg, 0, 1);
+ (void)smp_call_function(model-cpu_setup, reg, 0, 1);
model-cpu_setup(reg);
return 0;
}
@@ -86,7 +86,7 @@ op_axp_cpu_start(void *dummy)
static int
op_axp_start(void)
{
- smp_call_function(op_axp_cpu_start, NULL, 0, 1);
+ (void)smp_call_function(op_axp_cpu_start, NULL, 0, 1);
op_axp_cpu_start(NULL);
return 0;
}
@@ -101,7 +101,7 @@ op_axp_cpu_stop(void *dummy)
static void
op_axp_stop(void)
{
- smp_call_function(op_axp_cpu_stop, NULL, 0, 1);
+ (void)smp_call_function(op_axp_cpu_stop, NULL, 0, 1);
op_axp_cpu_stop(NULL);
}
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] missing include in pcmcia_resource.c
tree 1bd14fc69b8c7b9afd04d7c2acb92809dd2abeb5 parent 18415e923e90b986db316abd078f6d863cee7b18 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:47:01 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:43 -0700 [PATCH] missing include in pcmcia_resource.c missing include of asm/irq.h Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/pcmcia/pcmcia_resource.c |1 + 1 files changed, 1 insertion(+) diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c --- a/drivers/pcmcia/pcmcia_resource.c +++ b/drivers/pcmcia/pcmcia_resource.c @@ -41,6 +41,7 @@ module_param(io_speed, int, 0444); #ifdef CONFIG_PCMCIA_PROBE +#include asm/irq.h /* mask of IRQs already reserved by other cards, we should avoid using them */ static u8 pcmcia_used_irq[NR_IRQS]; #endif - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] alpha xchg fix
tree bcc10e8f4f576d525b4f2a617010f49077d03e6f
parent 531e5ca62bd9aabef6bd8340d8ae93bac1b5caa2
author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:47:07 +0100
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:44 -0700
[PATCH] alpha xchg fix
alpha xchg has to be a macro - alpha disables always_inline and if that
puppy does not get inlined, we immediately blow up on undefined reference.
Happens even on gcc3; with gcc4 that happens a _lot_.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
include/asm-alpha/system.h | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/include/asm-alpha/system.h b/include/asm-alpha/system.h
--- a/include/asm-alpha/system.h
+++ b/include/asm-alpha/system.h
@@ -443,22 +443,19 @@ __xchg_u64(volatile long *m, unsigned lo
if something tries to do an invalid xchg(). */
extern void __xchg_called_with_bad_pointer(void);
-static inline unsigned long
-__xchg(volatile void *ptr, unsigned long x, int size)
-{
- switch (size) {
- case 1:
- return __xchg_u8(ptr, x);
- case 2:
- return __xchg_u16(ptr, x);
- case 4:
- return __xchg_u32(ptr, x);
- case 8:
- return __xchg_u64(ptr, x);
- }
- __xchg_called_with_bad_pointer();
- return x;
-}
+#define __xchg(ptr, x, size) \
+({ \
+ unsigned long __xchg__res; \
+ volatile void *__xchg__ptr = (ptr); \
+ switch (size) { \
+ case 1: __xchg__res = __xchg_u8(__xchg__ptr, x); break; \
+ case 2: __xchg__res = __xchg_u16(__xchg__ptr, x); break; \
+ case 4: __xchg__res = __xchg_u32(__xchg__ptr, x); break; \
+ case 8: __xchg__res = __xchg_u64(__xchg__ptr, x); break; \
+ default: __xchg_called_with_bad_pointer(); __xchg__res = x; \
+ } \
+ __xchg__res; \
+})
#define xchg(ptr,x) \
({\
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] alpha spinlock code and bogus constraints
tree 1089c4acaa09ace254aecd72b118891f8f23aa07
parent 79fb7bdce363685b336e3f0fb8207312fd1f02fc
author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:47:12 +0100
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:44 -0700
[PATCH] alpha spinlock code and bogus constraints
=m (lock-lock) / 1 (lock-lock) makes gcc4 unhappy; fixed by s/1/m/,
same as in case of i386 rwsem.h where such variant had been accepted
by both Linus and rth.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
arch/alpha/kernel/smp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -1036,7 +1036,7 @@ debug_spin_lock(spinlock_t * lock, const
br 1b\n
.previous
: =r (tmp), =m (lock-lock), =r (stuck)
- : 1 (lock-lock), 2 (stuck) : memory);
+ : m (lock-lock), 2 (stuck) : memory);
if (stuck 0) {
printk(KERN_WARNING
@@ -1115,7 +1115,7 @@ void _raw_write_lock(rwlock_t * lock)
.previous
: =m (*(volatile int *)lock), =r (regx), =r (regy),
=r (stuck_lock), =r (stuck_reader)
- : 0 (*(volatile int *)lock), 3 (stuck_lock), 4 (stuck_reader) :
memory);
+ : m (*(volatile int *)lock), 3 (stuck_lock), 4 (stuck_reader) :
memory);
if (stuck_lock 0) {
printk(KERN_WARNING write_lock stuck at %p\n, inline_pc);
@@ -1153,7 +1153,7 @@ void _raw_read_lock(rwlock_t * lock)
br 1b\n
.previous
: =m (*(volatile int *)lock), =r (regx), =r (stuck_lock)
- : 0 (*(volatile int *)lock), 2 (stuck_lock) : memory);
+ : m (*(volatile int *)lock), 2 (stuck_lock) : memory);
if (stuck_lock 0) {
printk(KERN_WARNING read_lock stuck at %p\n, inline_pc);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] m32r_sio gcc4 fixes
tree d2a88ac07bb1d834c33943242f8b57ffdf1cd429
parent c51d9943b11441fd1ea42c7e70cfb5eed33fe97b
author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:47:27 +0100
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:44 -0700
[PATCH] m32r_sio gcc4 fixes
extern declaration followed by static in drivers/serial/m32r_sio.c
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
drivers/serial/m32r_sio.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
--- a/drivers/serial/m32r_sio.c
+++ b/drivers/serial/m32r_sio.c
@@ -1123,7 +1123,7 @@ static int __init m32r_sio_console_setup
return uart_set_options(port, co, baud, parity, bits, flow);
}
-extern struct uart_driver m32r_sio_reg;
+static struct uart_driver m32r_sio_reg;
static struct console m32r_sio_console = {
.name = ttyS,
.write = m32r_sio_console_write,
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] broken inline asm on s390 (misuse of labels)
tree 4b7ccdab07948b5a80f28d73cc9ecb04f67c754c parent a828b8e4e699b5e3ce0dcbb708ecb099b86f3126 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:47:32 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:44 -0700 [PATCH] broken inline asm on s390 (misuse of labels) use of explicit labels in inline asm is a Bad Idea(tm), since gcc can decide to inline the function in several places. Fixed by use of 1f/f: instead of .Lfitsin/.Lfitsin: Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/s390/kernel/cpcmd.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/s390/kernel/cpcmd.c b/arch/s390/kernel/cpcmd.c --- a/arch/s390/kernel/cpcmd.c +++ b/arch/s390/kernel/cpcmd.c @@ -46,9 +46,9 @@ int __cpcmd(const char *cmd, char *resp lra3,0(%4)\n lr 5,%5\n diag 2,4,0x8\n - brc8, .Litfits\n + brc8, 1f\n ar 5, %5\n - .Litfits: \n + 1: \n lr %0,4\n lr %1,5\n : =d (return_code), =d (return_len) @@ -64,9 +64,9 @@ int __cpcmd(const char *cmd, char *resp sam31\n diag 2,4,0x8\n sam64\n - brc8, .Litfits\n + brc8, 1f\n agr5, %5\n - .Litfits: \n + 1: \n lgr%0,4\n lgr%1,5\n : =d (return_code), =d (return_len) - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] m32r icu_data gcc4 fixes
tree 18f2694b421cba1e0160db3781346d577a1e9b5a
parent e231a9c4fdf402bcfd5a7c27be49050882631a95
author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:47:22 +0100
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:44 -0700
[PATCH] m32r icu_data gcc4 fixes
either icu_data declaration for SMP case should be taken out of m32102.h,
or its declarations for m32700ut and opsput should not be static for SMP.
Patch does the latter - judging by comments in m32102.h it is intended to
be non-static.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
arch/m32r/kernel/setup_m32700ut.c |4 +++-
arch/m32r/kernel/setup_opsput.c |4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/m32r/kernel/setup_m32700ut.c
b/arch/m32r/kernel/setup_m32700ut.c
--- a/arch/m32r/kernel/setup_m32700ut.c
+++ b/arch/m32r/kernel/setup_m32700ut.c
@@ -30,9 +30,11 @@
typedef struct {
unsigned long icucr; /* ICU Control Register */
} icu_data_t;
+static icu_data_t icu_data[M32700UT_NUM_CPU_IRQ];
+#else
+icu_data_t icu_data[M32700UT_NUM_CPU_IRQ];
#endif /* CONFIG_SMP */
-static icu_data_t icu_data[M32700UT_NUM_CPU_IRQ];
static void disable_m32700ut_irq(unsigned int irq)
{
diff --git a/arch/m32r/kernel/setup_opsput.c b/arch/m32r/kernel/setup_opsput.c
--- a/arch/m32r/kernel/setup_opsput.c
+++ b/arch/m32r/kernel/setup_opsput.c
@@ -31,9 +31,11 @@
typedef struct {
unsigned long icucr; /* ICU Control Register */
} icu_data_t;
+static icu_data_t icu_data[OPSPUT_NUM_CPU_IRQ];
+#else
+icu_data_t icu_data[OPSPUT_NUM_CPU_IRQ];
#endif /* CONFIG_SMP */
-static icu_data_t icu_data[OPSPUT_NUM_CPU_IRQ];
static void disable_opsput_irq(unsigned int irq)
{
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (missing dependencies on PCI in sound/*)
tree c238d57648a893504b0dc20fca42f986d71ed50e parent eaaece266a78b8f56ade48fe23147b8b933364de author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:48:02 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:46 -0700 [PATCH] Kconfig fix (missing dependencies on PCI in sound/*) a bunch of PCI-only drivers didn't have the right dependency Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] sound/oss/Kconfig | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -6,7 +6,7 @@ # Prompt user for primary drivers. config SOUND_BT878 tristate BT878 audio dma - depends on SOUND_PRIME + depends on SOUND_PRIME PCI ---help--- Audio DMA support for bt878 based grabber boards. As you might have already noticed, bt878 is listed with two functions in /proc/pci. @@ -87,7 +87,7 @@ config MIDI_EMU10K1 config SOUND_FUSION tristate Crystal SoundFusion (CS4280/461x) - depends on SOUND_PRIME + depends on SOUND_PRIME PCI help This module drives the Crystal SoundFusion devices (CS4280/46xx series) when wired as native sound drivers with AC97 codecs. If @@ -95,7 +95,7 @@ config SOUND_FUSION config SOUND_CS4281 tristate Crystal Sound CS4281 - depends on SOUND_PRIME + depends on SOUND_PRIME PCI help Picture and feature list at http://www.pcbroker.com/crystal4281.html. @@ -179,7 +179,7 @@ config SOUND_HARMONY config SOUND_SONICVIBES tristate S3 SonicVibes - depends on SOUND_PRIME + depends on SOUND_PRIME PCI help Say Y or M if you have a PCI sound card utilizing the S3 SonicVibes chipset. To find out if your sound card uses a @@ -226,7 +226,7 @@ config SOUND_AU1550_AC97 config SOUND_TRIDENT tristate Trident 4DWave DX/NX, SiS 7018 or ALi 5451 PCI Audio Core - depends on SOUND_PRIME + depends on SOUND_PRIME PCI ---help--- Say Y or M if you have a PCI sound card utilizing the Trident 4DWave-DX/NX chipset or your mother board chipset has SiS 7018 - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cpu_exclusive sched domains on partial nodes temp fix
tree c81c261274011d301dfbcfd1a3e13480b93c167e
parent ae75784bc576a1af70509c2f3ba2b70bb65a0c58
author Paul Jackson [EMAIL PROTECTED] Tue, 23 Aug 2005 15:04:27 -0700
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 10:02:52 -0700
[PATCH] cpu_exclusive sched domains on partial nodes temp fix
This keeps the kernel/cpuset.c routine update_cpu_domains() from
invoking the sched.c routine partition_sched_domains() if the cpuset in
question doesn't fall on node boundaries.
I have boot tested this on an SN2, and with the help of a couple of ad
hoc printk's, determined that it does indeed avoid calling the
partition_sched_domains() routine on partial nodes.
I did not directly verify that this avoids setting up bogus sched
domains or avoids the oops that Hawkes saw.
This patch imposes a silent artificial constraint on which cpusets can
be used to define dynamic sched domains.
This patch should allow proceeding with this new feature in 2.6.13 for
the configurations in which it is useful (node alligned sched domains)
while avoiding trying to setup sched domains in the less useful cases
that can cause the kernel corruption and oops.
Signed-off-by: Paul Jackson [EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Acked-by: Dinakar Guniguntala [EMAIL PROTECTED]
Acked-by: John Hawkes [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
kernel/cpuset.c | 17 +
1 files changed, 17 insertions(+)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -636,6 +636,23 @@ static void update_cpu_domains(struct cp
return;
/*
+* Hack to avoid 2.6.13 partial node dynamic sched domain bug.
+* Require the 'cpu_exclusive' cpuset to include all (or none)
+* of the CPUs on each node, or return w/o changing sched domains.
+* Remove this hack when dynamic sched domains fixed.
+*/
+ {
+ int i, j;
+
+ for_each_cpu_mask(i, cur-cpus_allowed) {
+ for_each_cpu_mask(j, node_to_cpumask(cpu_to_node(i))) {
+ if (!cpu_isset(j, cur-cpus_allowed))
+ return;
+ }
+ }
+ }
+
+ /*
* Get all cpus from parent's cpus_allowed not part of exclusive
* children
*/
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Kconfig fix (infiniband and PCI)
tree 6b1e668b1c7ccba11f88478413509906f5bbfd9b parent 697ae16ac0482283741f42378108b67b492870e8 author Al Viro [EMAIL PROTECTED] Tue, 23 Aug 2005 22:45:41 +0100 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 08:43:41 -0700 [PATCH] Kconfig fix (infiniband and PCI) infiniband uses PCI helpers all over the place (including the core parts) and won't build without PCI. Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/infiniband/Kconfig |1 + 1 files changed, 1 insertion(+) diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig --- a/drivers/infiniband/Kconfig +++ b/drivers/infiniband/Kconfig @@ -1,6 +1,7 @@ menu InfiniBand support config INFINIBAND + depends on PCI || BROKEN tristate InfiniBand support ---help--- Core support for InfiniBand (IB). Make sure to also select - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-ls-new-files make patch, pull, etc.
Hi, On Mon, 22 Aug 2005, Jeff Carr wrote: patch: git-diff-files -p git diff push: git-send-pack `cat .git/branches/origin` git push origin (or maybe git push HEAD:origin) pull: git-pull-script `cat .git/branches/origin` git-read-tree -m HEAD git-checkout-cache -q -f -u -a git pull origin commit: vi changelog.txt GIT_AUTHOR_NAME=$(GIT_AUTHOR_NAME) \ GIT_AUTHOR_EMAIL=$(GIT_AUTHOR_EMAIL) \ git-commit-tree `git-write-tree` -p $(HEAD) changelog.txt .git/HEAD rm changelog.txt git commit add_all: ./git-ls-new-files |xargs -n 1 git-update-cache --add git add $(git ls-files --others) Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-rev-parse question.
I have been looking at what git-rev-parse does and could not figure out a way to convince it to give me only arguments with a '-' prefix. Specifically, I wanted to remove the hardcoded -p and -M flags from git-diff-script. Running $ sh -x git-diff-script -C HEAD^ HEAD reveals that none of the following would pick up -C from the command line: rev=($(git-rev-parse --revs-only $@)) || exit flags=($(git-rev-parse --no-revs --flags $@)) files=($(git-rev-parse --no-revs --no-flags $@)) I am not even sure if the current implementation of rev-parse matches what you originally wanted it to do; I suspect it does not. I would like to know what was the intended behaviour first, so that I can enhance it to be usable for my purpose without breaking things. What I want the rev-parse flags to mean is as follows. By rev argument, I mean what get_sha1() can understand. I have to admit that some flags are what I introduced while I was butchering it without really knowing the original intention: output format: --sq output in a format usable for shell eval. --symbolicoutput rev argument in symbolic form, not SHA1. output selection: --flags show only arguments with '-' prefix. --no-flagsdo not show arguments with '-' prefix. --revs-only show only arguments meant for rev-list. --no-revs show arguments not meant for rev-list. input munging: --default R if no revision, pretend R is given. --not pretend all rev arguments without prefix ^ have prefix ^, and the ones with prefix ^ do not. --all pretend all refs under $GIT_DIR/refs are given on the command line. special: --verify make sure only one rev argument is given, nothing else. I think flags/no-flags and revs-only/no-revs *should* be orthogonal. That is, rev-parse --flags --no-revs should give parameters that start with '-' and not meant for rev-list (e.g. '-C' in earlier example); rev-parse --revs-only --merge-order HEAD Documentation/ should yield --merge-order HEAD. Also there is an undocumented --show-prefix. What is it? -jc PS. BTW, any response about unsuspecting companies? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] cg-log -r order:matters
It's sometimes unclear which head is ahead of the other. If I get the order wrong, cg-log shows no log output. Is this expected? I was expecting a warning, or a reverse-ordered log. Or both. ;) martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch2git import script
On 8/24/05, Martin Langhoff [EMAIL PROTECTED] wrote: First draft of an Arch import. And now, with sample script attached, too. cheers, martin git-archimport-script Description: Binary data
Re: cg-update/cg-merge refuse to update if state is dirty?
Hello,
Here's a thought. It might be nice, in this situation, to have
something like a git-undo-script that can undo the changes in the index
storing them in a tree object but not wrapping them into a commit. A
ref to the tree can be stored in an 'undo' file somewhere under .git.
When the merge is done then a git-redo-script can retrieve and merge
that tree back into the index. This way, cg-{merge,update} could refuse
--- which I tend to think it should --- to merge into a dirty tree but
it wouldn't be so inconvenient.
cogito would handle synchronization with the working copy like normal.
Carl
On Tue, Aug 23, 2005 at 08:09:04PM +1200, Martin Langhoff wrote:
Should cg-update or cg-merge be refusing to merge if the tree is
dirty? If there are uncommitted files, and the merge fails, a lot of
unrelated changes will be dumped on the working tree, which ends up
with a mix of things.
cheers,
martin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
Fort Collins, CO 80525 home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Removing deleted files after checkout
Hello, I recently started using git to revision control the source for my web-page. I wrote a post-update hook to checkout the files when I push to the 'live' repository. In this particular context I decided that it was important to me to remove deleted files after checking out the new HEAD. I accomplished this by running git-ls-files before and after the checkout. Is there a better way? Could there be some way built into git to easily find out what files dissappear when replacing the current index with one from a new tree? Is there already? The behavior of git should NOT change to delete these files but I would argue that some way should exist to query what files disappeared if removing them is desired. Here is some code that I wrote for this. It feels a bit hackish to me but I couldn't think of anything better. Comments and criticism are welcome. #!/bin/sh # HEAD changed so checkout the new HEAD deleted any files that should no longer # be around. oldlist=$(tempfile) newlist=$(tempfile) removedlist=$(tempfile) git-ls-files | sort -r $oldlist git-checkout-script -f git-ls-files | sort -r $newlist diff -u $oldlist $newlist | tail -n +4 | sed -n 's/^-//p' $removedlist # Remove each file cat $removedlist | xargs -rl rm -f # Remove the directories if empty cat $removedlist | xargs -rl dirname | xargs -rl rmdir -p --ignore-fail-on-non-empty rm -f $oldlist $newlist $removedlist # --- snip --- If you are interested I attached the full post-update hook script that I actually use to do this. Again, comments are welcome. Thanks, Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/bin/sh export PATH=/usr/local/bin:/usr/bin:/bin # cd to the root of the project directory (assume one dir up from GIT_DIR) cd $GIT_DIR/.. unset GIT_DIR # Set up some temporary files and a trap to delete them oldlist=$(tempfile) newlist=$(tempfile) removelist=$(tempfile) trap rm -f $oldlist $newlist $removelist 0 1 2 3 15 # Get list of files from the current index git-ls-files | sort -r $oldlist # Checkout the index to the working directory git-checkout-script -f # Get list of files from the current (new) index git-ls-files | sort -r $newlist # Use diff to determine which files to remove from the working copy diff -u $oldlist $newlist | tail -n +4 | sed -n 's/^-//p' $removelist cat $removelist | xargs -rl rm -f cat $removelist | xargs -rl dirname | xargs -rl rmdir -p --ignore-fail-on-non-empty
[PATCH] Improve can_hardlink diagnostics, remove suggest_hardlink
Hello! suggest_hardlink is write-only in cg-pull - remove it. can_hardlink should not be shown to the user as is (it's either l or empty) - we should output something meaningful instead. Signed-off-by: Pavel Roskin [EMAIL PROTECTED] diff --git a/cg-pull b/cg-pull --- a/cg-pull +++ b/cg-pull @@ -207,7 +207,6 @@ fetch_local() cp_flags_l=-vdpR if [ $1 = -u ]; then cp_flags_l=$cp_flags_l -fu$can_hardlink - suggest_hardlink= shift fi @@ -293,12 +292,16 @@ else symlinked= is_same_repo $_git_objects $uri/objects symlinked=1 - # See if we can hardlink and drop l if not. + # See if we can hardlink and add -l to cp flags. can_hardlink= sample_file=$(find $uri -type f -print | head -n 1) rm -f $_git/.,,lntest - ln $sample_file $_git/.,,lntest 2/dev/null can_hardlink=l - echo $can_hardlink + if cp -fl $sample_file $_git/.,,lntest 2/dev/null; then + can_hardlink=l + echo Using hard links + else + echo Hard links don't work - using copy + fi rm -f $_git/.,,lntest fi -- Regards, Pavel Roskin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
Daniel Barkalow [EMAIL PROTECTED] wrote: One factor not mentioned there is that, as things move upstream, we often want to discard a lot of history; if someone commits constantly to deal with editor malfunction or something, we don't really want to take all of this junk into the project history when it is cleaned up and accepted. That's true but Jan's proposal is to choose which commits to preserve in the history via a 'freeze' command. That's a bit difficult to implement in a clean way since the patches are floating on top of the stack base and they change every time the base changes. It is possible that a previous frozen state might no longer apply on top of a new base. So the point is that there are things which are, in fact, parents, but we don't want to list them, because it's not desired information. What's the definition of a parent in GIT terms? What are the restriction for a commit object to be a parent? Can a parent be an arbitrarily chosen commit? Probably the right thing is to have two views of the stack: the internal view, showing what actually happened, and the external view, showing what would have happened if the developers had done everything right the first time. When you make changes to the series, this adds to the internal view and entirely replaces the external view. That's what I've been thinking. StGIT currently only implements the external view. An StGIT patch is a represented by a top and bottom commit objects. The bottom one is the same as the parent of the top commit. The patch is the diff between the top's tree id and the bottom's tree id. Jan's proposal is to allow a freeze command to save the current top hash and later be used as a second parent for the newly generated top. The problem I see with this approach is that (even for the internal view you described) the newly generated top will have two parents, new-bottom and old-top, but only the diff between new-top and new-bottom is meaningful. The diff between new-top and old-top (as a parent-child relation) wouldn't contain anything relevant to the patch but all the new changes to the base of the stack. Is the above an acceptable usage of the GIT DAG structure? I think that users will also want to discard the commits from the stack before rebasing in favor of the commits after, because (a) rebasing isn't all that interesting, especially if there's minimal merging, and (b) otherwise you'd get a ton of boring commits that obscure the interesting ones. StGIT does this currently. The old commit is no longer available and can be pruned (I still need to save the commits corresponding to the unpushed patches since prune would remove those as well). I think that the best rule would be that, when you modify a patch, the previous version is the new version's parent, and when you rebase a series, you include as a parent any parent of the input that isn't also in the input (but never include the input itself as a parent of the output; the point of rebasing is to pretend that it was the newer mainline that you modified). This should mean that the internal history of a patch consists of the present version, based on each version that was replaced due to changing the patch rather than rebasing it. Since you proposed this, my above usage of the DAG structure would be fine then. Of course, there's an interesting situation with the commits earlier in a series from a patch that was changed not being ancestors of the newer versions of those patches (because they weren't interesting in the development of those patches) but accessible as the commits that an interesting patch was based on. A possible solution is just to consider the revision of any patch a significant event in the history of the whole stack, causing all of the patches to get a new retained version. That's another idea to think about. -- Catalin P.S. I'll be away until next week and not able to follow-up the discussions. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-rev-parse question.
On Tue, 23 Aug 2005, Junio C Hamano wrote: I have been looking at what git-rev-parse does and could not figure out a way to convince it to give me only arguments with a '-' prefix. Gaah. Understandable. It got broken during some cleanup. Try this trivial patch, it should work better. NOTE! The behaviour of -- for git-rev-parse is somewhat unclear. Right now it prints it out with --flags, which is probably wrong. Linus --- Subject: Fix git-rev-parse --default and --flags handling This makes the argument to --default and any --flags arguments should up correctly. Signed-off-by: Linus Torvalds [EMAIL PROTECTED] --- diff --git a/rev-parse.c b/rev-parse.c --- a/rev-parse.c +++ b/rev-parse.c @@ -107,7 +107,7 @@ static void show_arg(char *arg) if (do_rev_argument is_rev_argument(arg)) show_rev_arg(arg); else - show_norev(arg); + show(arg); } static void show_default(void) @@ -122,7 +122,7 @@ static void show_default(void) show_rev(NORMAL, sha1, s); return; } - show_arg(s); + show(s); } } - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Current status toward 0.99.5 and beyond
Some people may have noticed that the progress of the master branch head has somewhat slowed down lately, and I have kept some changes in the proposed updates branch for quite some time. There are two reasons for this. One is that I've been quite busy during my day job hours, and haven't had enough time to make sure the multi-head fetch stuff does not break things and the way it works is reasonable. Another is that I am feeling guilty about letting Documentation go stale, and am reluctant to have what is in the proposed updates branch graduate to the master branch without accompanying documentation. Maybe I'll have some time on my next GIT day [*1*]. Anyway, here is my updated Itchlist, as a preview of what comes next. For 0.99.5, I would like to finish testing and documenting what is currently in the proposed updates branch. There are two changes there: multi-head fetch and $GIT_DIR/remotes/ that somewhat deprecates $GIT_DIR/branches/; semantics cleanup of git reset command. Linus has been feeding updates to make various commands to be capable of running from subdirectories and taking paths relative to the current directory. I would have liked these patches with test scripts to demonstrate they do what they claim to do well. Patches to extend existing test scripts in t/ directory are very much welcomed. So far, the following commands should be usable with relative directory paths: update-cache ls-files diff-files diff-cache diff-tree I do not have major itch after 0.99.5 right now, except for obvious fixes and tweaks here and there [*2*]. I think we would concentrate a bit more on usability enhancement including the tutorial updates. One code change I would like to see is to add limited MIME support to applymbox suite. We should be able to teach mailinfo to: - detect B encoding in the mail headers, and translate it to UTF-8; - understand a single level multipart and pick out the body of the message; - detect QP in the body and decode into the original charset; - after splitting the body into commit log and patch, translate only the commit log part into UTF-8. [Footnote] *1* Currently, my Wednesdays and Saturdays are for GIT only. *2* Here is a list of minor itches: * git rebase could be a bit more tolerant to conflicting patches. We may want to wiggle it, or may want to run 3-way merge. * The semantics of rev-parse needs to be clarified. * show-branch may want to show things in topological order, not time-based order. * There are commands that were well intentioned but not useful in practice, like build-rev-cache. I would like to review them for removal. * Cloning a packed repository over HTTP should work natively now. Update git clone and remove git-clone-dumb-http. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status toward 0.99.5 and beyond
On Tue, 23 Aug 2005, Junio C Hamano wrote:
So far, the following commands should be usable with relative directory
paths:
update-cache
ls-files
diff-files
diff-cache
diff-tree
Also, git-rev-parse.
Finally, this trivial patch makes git-rev-list also able to handle not
being in the top-level directory, which makes it possible to do git log
and git-whatchanged at any point in the directory structure.
Linus
---
Subject: Make git-rev-list work within subdirectories
This trivial patch makes git-rev-list able to handle not being in the
top-level directory. This magically also makes git-whatchanged do the
right thing.
Trivial scripting fix to make sure that git log also works.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/git-log-script b/git-log-script
--- a/git-log-script
+++ b/git-log-script
@@ -1,5 +1,4 @@
#!/bin/sh
-. git-sh-setup-script || die Not a git archive
-revs=$(git-rev-parse --revs-only --default HEAD $@)
+revs=$(git-rev-parse --revs-only --default HEAD $@) || exit
[ $revs ] || die No HEAD ref
git-rev-list --pretty $(git-rev-parse --default HEAD $@) | LESS=-S
${PAGER:-less}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -481,6 +481,7 @@ static void handle_one_commit(struct com
int main(int argc, char **argv)
{
struct commit_list *list = NULL;
+ const char *prefix = setup_git_directory();
int i, limited = 0;
for (i = 1 ; i argc; i++) {
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-rev-parse question.
On Tue, 23 Aug 2005, Linus Torvalds wrote:
Try this trivial patch, it should work better.
Actually, don't do the show_default() part of this. We should _not_ show
the default string if we haev --no-revs and the string doesn't match a
rev.
Also, this fixes -- handlign with --flags. Thinking about it for a
few seconds made it obvious that we shouldn't show it.
Linus
---
Subject: Fix git-rev-parse --default and --flags handling
This makes the argument to --default and any --flags arguments should up
correctly, and makes -- together with --flags act sanely.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -107,7 +107,7 @@ static void show_arg(char *arg)
if (do_rev_argument is_rev_argument(arg))
show_rev_arg(arg);
else
- show_norev(arg);
+ show(arg);
}
static void show_default(void)
@@ -122,7 +122,7 @@ static void show_default(void)
show_rev(NORMAL, sha1, s);
return;
}
- show_arg(s);
+ show_norev(s);
}
}
@@ -149,7 +149,7 @@ int main(int argc, char **argv)
if (*arg == '-') {
if (!strcmp(arg, --)) {
show_default();
- if (revs_only)
+ if (revs_only || flags_only)
break;
as_is = 1;
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
On Tue, 23 Aug 2005, Catalin Marinas wrote: So the point is that there are things which are, in fact, parents, but we don't want to list them, because it's not desired information. What's the definition of a parent in GIT terms? What are the restriction for a commit object to be a parent? Can a parent be an arbitrarily chosen commit? Something is legitimate as a parent if someone took that commit and did something to it to get the new commit. The operation which caused the change is not specified. But you only want to include it if anyone cares about the parent. (For example, I often start with a chunk of work that does multiple things and is committed; I take mainline and generate a series of commits from there. It would be legitimate to list my development commit as a parent of each of these, since I did actually take it and strip out the unrelated changes. This would be a bit confusing in the log, but would make merges between something based on the messy version and something based on the refined version work well. On the other hand, I don't want to report the existance of the messy version, so I don't include it.) An StGIT patch is a represented by a top and bottom commit objects. The bottom one is the same as the parent of the top commit. The patch is the diff between the top's tree id and the bottom's tree id. Jan's proposal is to allow a freeze command to save the current top hash and later be used as a second parent for the newly generated top. The problem I see with this approach is that (even for the internal view you described) the newly generated top will have two parents, new-bottom and old-top, but only the diff between new-top and new-bottom is meaningful. The diff between new-top and old-top (as a parent-child relation) wouldn't contain anything relevant to the patch but all the new changes to the base of the stack. Having a useful diff isn't really a requirement for a parent; the diff in the case of a merge is going to be the total of everything that happened elsewhere. The point is to be able to reach some commits between which there are interesting diffs. This also depends on how exactly freeze is used; if you use it before commiting a modification to the patch without rebasing, you get: old-top - new-top ^^ \ / bottom bottom to old-top is the old patch bottom to new-top is the new patch old-top to new-top is the change to the patch Then you want to keep new-top as a parent for rebasings until one of these is frozen. These links are not interesting to look at, but preserve the path to the old-top:new-top change, which is interesting. Ignoring the links to the corresponding bottoms, the development therefore looks like: local1 - local2 - merge - local3 - merge ^ ^ ^ mainline And this is how development is normally supposed to look. The trick is to only include a minimal number of merges. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Removing deleted files after checkout
On Tue, 23 Aug 2005, Carl Baldwin wrote: Hello, I recently started using git to revision control the source for my web-page. I wrote a post-update hook to checkout the files when I push to the 'live' repository. In this particular context I decided that it was important to me to remove deleted files after checking out the new HEAD. I accomplished this by running git-ls-files before and after the checkout. Is there a better way? Could there be some way built into git to easily find out what files dissappear when replacing the current index with one from a new tree? Is there already? The behavior of git should NOT change to delete these files but I would argue that some way should exist to query what files disappeared if removing them is desired. If you don't use -f, git-checkout-script removes deleted files. Using -f tells it to ignore the old index, which means that it can't tell the difference between removed files and files that weren't tracked at all. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improve handling of . and .. in git-diff-*
On 8/17/05, Linus Torvalds [EMAIL PROTECTED] wrote:
NOTE! This does _not_ handle .. or . in the _middle_ of a pathspec. If
you have people who do
BTW, could this (below) be useful for something?
#include string.h
#include stdio.h
#include stdlib.h
// an analog of cd path from a directory cwd.
char* pathexpand(const char* cwd, const char* path)
{
static const char SEP[] = /;
if ( !*path ) // empty path - . (don't move)
path = .;
if ( !*cwd || *SEP == *path ) // no cwd, or path begins with /
cwd = SEP;
int len = strlen(cwd);
char* out = (char*)malloc(len + 1 + strlen(path) + 1);
char* p = strcpy(out, cwd) + len;
if ( *SEP != p[-1] )
*p++ = *SEP;
for ( ; *path; ++path )
{
char * pl = p;
while ( *path *SEP != *path )
*p++ = *path++;
*p = '\0';
if ( p == pl ) /* ...//... */
; // just ignore
/* ..././... */
else if ( p - pl == 1 '.' == *pl )
--p; // just ignore
/* .../../... */
else if ( p - pl == 2 '.' == pl[0] '.' == pl[1] )
{
// drop last element of the resulting path
if ( --pl out )
for ( --pl; pl out *SEP != *pl; --pl );
p = ++pl;
}
/* .../path/... */
else if ( *path )
*p++ = *path; // just add the separator
if ( !*path )
break;
}
if ( p out+1 *SEP == p[-1] )
--p;
*p = '\0';
return out;
}
#ifdef CHECK_PATHEXPAND
static void check(const char * cwd, const char * path, const char * good)
{
static int n = 0;
printf(%-2d: %s$ cd %s, ++n, cwd, path);
char* t = pathexpand(cwd, path);
if ( strcmp(t, good) )
printf( failed(%s)\n, t);
else
printf( \t\t%s\n, t);
free(t);
}
int main(int argc, char** argv)
{
/* 1 */ check(/onelevel, aa, /onelevel/aa);
/* 2 */ check(/, .., /);
/* 3 */ check(/, ../.., /);
/* 4 */ check(/one, aa/../bb, /one/bb);
/* 5 */ check(/one/two, aa//bb, /one/two/aa/bb);
/* 6 */ check(, /aa//bb, /aa/bb);
/* 7 */ check(/one/two, , /one/two);
/* 8 */ check(/one/two, aa/..bb/x/../cc/, /one/two/aa/..bb/cc);
/* 9 */ check(/one/two, aa/x/././cc, /one/two/aa/x/cc);
/* 10 */ check(/one/two, ../../../../aa, /aa);
return 0;
}
#endif
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improve handling of . and .. in git-diff-*
On 8/23/05, Alex Riesen [EMAIL PROTECTED] wrote: On 8/17/05, Linus Torvalds [EMAIL PROTECTED] wrote: NOTE! This does _not_ handle .. or . in the _middle_ of a pathspec. If you have people who do BTW, could this (below) be useful for something? Well, a bit of explanation is certainly missing, sorry. The code tries to emulate (on purely text level) the behaviour of chdir(2), including stopping at root, going back and forth and removing useless (not changing directory) parts like /./. The file in the previous message can be tested with : gcc -DCHECK_PATHEXPAND patchexpand.c ./aout Cheers, Alex Riesen. PS: Before anyone asked: the code is mine and free for any use. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce reset type flag to git reset
I am not sure what mixed reset (the current behaviour) is good for. If nobody comes up with a good use case it may not be a bad idea to remove it. Using the principle of minimum suprise the --mixed should be removed. --soft - undo the commit leaving all changes. --hard - undo the commit and removing all changes I'm a cogito user so not used to got options. But --soft, --hard looks rather confusing to me. Something like --force or --prune may be a bit more intuitive, and let default behaviour be the one you name --soft for now. I think it would make sense to be able to specify the topmost SHA1 (or HEAD:5 or HEAD^) from where the reset should start. Sam - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
Daniel Barkalow wrote: On Tue, 23 Aug 2005, Catalin Marinas wrote: Something is legitimate as a parent if someone took that commit and did something to it to get the new commit. The operation which caused the change is not specified. But you only want to include it if anyone cares about the parent. This is indeed what I thought a parent should be used for. As an adition, I'll try to explain why I would sometimes want to care about some parents: I want to track a mailine tree, but have quite a few changes, which shoudn't be commited to the mainline immediately (let's call it my development tree). This is why I would use stgit. But I would also want to colaborate with other developers on this development tree, so I sometimes want to make updates available of this development tree to the others. This is where current stgit falls short. To easily share this development tree, I want some history (not all, only the ones I choose) of this development tree included, so that the other developers can easily follow my development. The parents which should be visible to the outside, will always be versions of my development tree, which I have previously pushed out. My way of working would become: * make changes, all over the place, using stgit * still make changes (none of these gets tracked, intermittent versions are lost) * having a good day: changes looks good, I want to push this out: * push my tree out * stgit-free (which makes the pushed out commits, the new parents of my stgit patches) * restart from top [...] This also depends on how exactly freeze is used; if you use it before commiting a modification to the patch without rebasing, you get: old-top - new-top ^^ \ / bottom bottom to old-top is the old patch bottom to new-top is the new patch old-top to new-top is the change to the patch Then you want to keep new-top as a parent for rebasings until one of these is frozen. These links are not interesting to look at, but preserve the path to the old-top:new-top change, which is interesting. my proposal does something like this, but a little more: not only does it keep track of the link between old-top and new-top, it also keeps track of the links between old-patch-in-between and new-patch-in-between. (This makes sense when the top is being removed or reordered) I hope this kind of clarifies my intension. Thank you for clarifying the meaning of parents. Best regards, Jan - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Spell __attribute__ correctly in cache.h.
And Junio C Hamano writes: - BTW, how would people feel about replacing the - setenv() and unsetenv() calls with the older putenv()? - No comment on this one at this moment until I do my own digging - a bit. If you're interested, I have a few patches in http://www.cs.berkeley.edu/~ejr/gits/git.git#portable that let git compile with xlc on AIX and Sun's non-c99 cc on Solaris. Changes: +Replace C99 array initializers with code. +Replace unsetenv() and setenv() with older putenv(). +Include sys/time.h in daemon.c. +Fix ?: statements. +Replace zero-length array decls with []. The top two may or may not be acceptable. The third may not be necessary if I can find the right -Ds for fd_set. The last two just remove GNU C extensions. Makefile changes (including extra -Ds for features) not included, but could be. Tell me if you want any of these mailed. Not all the tests pass on non-Linux, but I won't have time to look at them for a bit. With the GNU findutils and coreutils, it works well enough for basic use. The failing tests might be from using non-GNU utilities. Rooting out all the dependencies is a tad painful. Jason - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Removing deleted files after checkout
On Tue, 23 Aug 2005, Carl Baldwin wrote: On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote: On Tue, 23 Aug 2005, Carl Baldwin wrote: Hello, I recently started using git to revision control the source for my web-page. I wrote a post-update hook to checkout the files when I push to the 'live' repository. In this particular context I decided that it was important to me to remove deleted files after checking out the new HEAD. I accomplished this by running git-ls-files before and after the checkout. Is there a better way? Could there be some way built into git to easily find out what files dissappear when replacing the current index with one from a new tree? Is there already? The behavior of git should NOT change to delete these files but I would argue that some way should exist to query what files disappeared if removing them is desired. If you don't use -f, git-checkout-script removes deleted files. Using -f tells it to ignore the old index, which means that it can't tell the difference between removed files and files that weren't tracked at all. Maybe I'm doing something wrong. This does not happen for me. I tried a simple test with git v0.99.4... cd mkdir test-git cd test-git/ echo testing | cg-init echo contents file git-add-script file git-commit-script -m 'testing' [point 1] cd .. cg-clone test-git/.git/ test-git2 cd test-git2 cg-rm file git-commit-script -m 'testing' ls cg-push cd ../test-git git-checkout-script Ah, okay. I think push and checkout don't play that well together; push changes the ref, which checkout uses to determine what it expects for the old contents, and then it's confused. What you probably actually want is: cd ../test-git git pull ../test-git2 which will correctly identify before and after, and remove any files that were removed. Alternatively, you could do, at point 1: cp .git/refs/master .git/refs/deployed git checkout deployed Then, after the push and cd: git checkout master cp .git/refs/master .git/refs/deployed git checkout deployed because checkout does remove files if you switch from a branch with them (e.g., deployed) to one without them (master, after the push). -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cg-pull to stop treating master specially, fix fetch_local for .git/HEAD
Hello!
This patch changes cg-pull so that if the branch is not specified, it
takes origin's .git/HEAD without first trying .git/refs/heads/master.
This removes preferential treatment of the master branch, allowing the
upstream to use another name for the default branch. To get the master
branch, users would have to append #master to the URL.
Local URL handling needs to be fixed to handle .git/HEAD properly, since
it's a symlink in the upstream directory. A new flag -b for fetch_*
functions is introduced, meaning dereference (like in GNU cp).
To do: the code needs refactoring with better option handling.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -67,6 +67,8 @@ pull_progress()
fetch_rsync()
{
+ [ $1 = -b ] shift
+
redir=
if [ $1 = -i ]; then # ignore-errors
redir=2/dev/null
@@ -108,6 +110,7 @@ pull_rsync()
fetch_http()
{
+ [ $1 = -b ] shift
[ $1 = -i ] shift
[ $1 = -s ] shift
@@ -158,6 +161,7 @@ pull_http()
fetch_ssh()
{
+ [ $1 = -b ] shift
[ $1 = -i ] shift
[ $1 = -s ] shift
@@ -205,6 +209,11 @@ fetch_local()
[ $1 = -s ] shift
cp_flags_l=-vdpR
+ if [ $1 = -b ]; then
+ cp_flags_l=-vb # Dereference symlinks
+ shift
+ fi
+
if [ $1 = -u ]; then
cp_flags_l=$cp_flags_l -fu$can_hardlink
suggest_hardlink=
@@ -255,7 +264,7 @@ name=${ARGS[0]}
[ $name ] || die where to pull from?
uri=$(cat $_git/branches/$name 2/dev/null) || die unknown branch: $name
-rembranch=master
+rembranch=
if echo $uri | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
uri=$(echo $uri | cut -d '#' -f 1)
@@ -308,13 +317,13 @@ orig_head=
mkdir -p $_git/refs/heads
-rsyncerr=
-$fetch -i $uri/refs/heads/$rembranch $_git/refs/heads/.$name-pulling ||
rsyncerr=1
-if [ $rsyncerr ] [ $rembranch = master ]; then
- rsyncerr=
- $fetch -s $uri/HEAD $_git/refs/heads/.$name-pulling || rsyncerr=1
+if [ $rembranch ]; then
+ $fetch -i $uri/refs/heads/$rembranch
$_git/refs/heads/.$name-pulling ||
+ die unable to get the head pointer of branch $rembranch
+else
+ $fetch -b -s $uri/HEAD $_git/refs/heads/.$name-pulling ||
+ die unable to get the HEAD branch
fi
-[ $rsyncerr ] die unable to get the head pointer of branch $rembranch
new_head=$(cat $_git/refs/heads/.$name-pulling)
if ! [ $symlinked ]; then
--
Regards,
Pavel Roskin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Removing deleted files after checkout
On Tue, 23 Aug 2005, Carl Baldwin wrote: The point is to push and use a post-update hook to do the checkout. So, this won't be possible. You could have the remote repository be something like ~/git/website.git, and have a hook which does: cd ~/www; git pull ~/git/website.git/. That is, have three things: the directory where you work on stuff, the central storage location, and the area that the web server serves, and have the storage location automatically update the web server area. That's what I do with my website section that's still in CVS, and the general concept is good (and means that the real repository isn't somewhere the web server is poking around). which will correctly identify before and after, and remove any files that were removed. Alternatively, you could do, at point 1: cp .git/refs/master .git/refs/deployed git checkout deployed How to get a post-update hook to do this? I suppose an update script could set this up for the post-update to later use. If you have deployed checked out, and you push to master in the same repository, having the hook do git resolve deployed master auto-update should work. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce reset type flag to git reset
Sam Ravnborg [EMAIL PROTECTED] writes: But --soft, --hard looks rather confusing to me. Something like --force or --prune may be a bit more intuitive, and let default behaviour be the one you name --soft for now. I do not have objections to removing --mixed, but I do not find --force/--prune any less confusing than --soft/--hard. Its just a terminology so once people get used to it anything would do. But I agree that we need to come up with a good name for them. I do not think --force/--prune is it, though. I think it would make sense to be able to specify the topmost SHA1 (or HEAD:5 or HEAD^) from where the reset should start. git reset --hard HEAD~5 should work. Sorry, the colon : turns out to be confusing to refspec notation src:dst used in fetch/push and was replaced with a tilde ~ some time ago. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Automatic merge failed, fix up by hand
Len Brown [EMAIL PROTECTED] writes: The merge issue below is reproduced in a git clone -l copy with no plain files present. Meaning you did not have any file in the working tree? It seems to me that what is happenning is the resolve is trying to merge the head of your tree and from-linus, but at the same time it notices that you removed those files from your working tree and thinks that is what you would want to do. I could get to 81065e2f415af6... commit (Linus tip at this moment), so if you can tell me where to snarf the other commit (702c7e76) that would help me diagnose the problem a lot. Thanks. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Removing deleted files after checkout
Daniel Barkalow [EMAIL PROTECTED] writes: If you don't use -f, git-checkout-script removes deleted files. Using -f tells it to ignore the old index, which means that it can't tell the difference between removed files and files that weren't tracked at all. Yes and no. git checkout assumes that the index file and the working tree somewhat resembles what is in .git/HEAD commit. Since push operation updates .git/HEAD commit without touching the index file, that assumption does not hold. The update hook gets old commit name and new commit name, so you should be able to do (untested): git-read-tree -m -u $old_commit $new_commit there, of course after making sure that you had old_commit (the first time push happens to a new ref you would not have that one). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
On Tue, 23 Aug 2005, Jan Veldeman wrote: Daniel Barkalow wrote: On Tue, 23 Aug 2005, Catalin Marinas wrote: Something is legitimate as a parent if someone took that commit and did something to it to get the new commit. The operation which caused the change is not specified. But you only want to include it if anyone cares about the parent. This is indeed what I thought a parent should be used for. As an adition, I'll try to explain why I would sometimes want to care about some parents: I want to track a mailine tree, but have quite a few changes, which shoudn't be commited to the mainline immediately (let's call it my development tree). This is why I would use stgit. But I would also want to colaborate with other developers on this development tree, so I sometimes want to make updates available of this development tree to the others. This is where current stgit falls short. To easily share this development tree, I want some history (not all, only the ones I choose) of this development tree included, so that the other developers can easily follow my development. The parents which should be visible to the outside, will always be versions of my development tree, which I have previously pushed out. My way of working would become: * make changes, all over the place, using stgit * still make changes (none of these gets tracked, intermittent versions are lost) * having a good day: changes looks good, I want to push this out: * push my tree out * stgit-free (which makes the pushed out commits, the new parents of my stgit patches) * restart from top I'm not sure how applicable to this situation stgit really is; I see stgit as optimized for the case of a patch set which is basically done, where you want to keep it applicable to the mainline as the mainline advances. For your application, I'd just have a git branch full of various stuff, and then generate clean commits by branching mainline, diffing development against it, cutting the diff down to just what I want to push, and applying that. Then the clean patch goes into stgit. [...] This also depends on how exactly freeze is used; if you use it before commiting a modification to the patch without rebasing, you get: old-top - new-top ^^ \ / bottom bottom to old-top is the old patch bottom to new-top is the new patch old-top to new-top is the change to the patch Then you want to keep new-top as a parent for rebasings until one of these is frozen. These links are not interesting to look at, but preserve the path to the old-top:new-top change, which is interesting. my proposal does something like this, but a little more: not only does it keep track of the link between old-top and new-top, it also keeps track of the links between old-patch-in-between and new-patch-in-between. (This makes sense when the top is being removed or reordered) I was thinking of this as being the top and bottom commits for a single tracked patch, not as a whole series. I think patches lower wouldn't be affected, and patches higher would see this as a rebase. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Removing deleted files after checkout
Ok, the following is what I came up with based on your response. This is .git/hooks/update. It mostly works in my situation. See below for my discussion on what didn't work. #!/bin/sh export PATH=/usr/local/bin:/usr/bin:/bin # cd to the root of the project directory (assume one dir up from GIT_DIR) cd $GIT_DIR/.. unset GIT_DIR if expr $2 : '0*$' /dev/null; then git-read-tree --reset $3 git-checkout-cache -q -f -u -a else git-read-tree -m -u $2 $3 fi exit 0 # --- snip --- The thing that this doesn't do is remove empty directories when the last file is deleted. I once expressed the opinion in a previous thread that directories should be added and removed explicitly in git. (Thus allowing an empty directory to be added). If this were to happen then this case would get handled correctly. However, if git stays with the status quo then I think that git-read-tree -u should be changed to remove the empty directory. This would make it consistent. What do you think? Ideas? Carl On Tue, Aug 23, 2005 at 02:54:30PM -0700, Junio C Hamano wrote: Daniel Barkalow [EMAIL PROTECTED] writes: If you don't use -f, git-checkout-script removes deleted files. Using -f tells it to ignore the old index, which means that it can't tell the difference between removed files and files that weren't tracked at all. Yes and no. git checkout assumes that the index file and the working tree somewhat resembles what is in .git/HEAD commit. Since push operation updates .git/HEAD commit without touching the index file, that assumption does not hold. The update hook gets old commit name and new commit name, so you should be able to do (untested): git-read-tree -m -u $old_commit $new_commit there, of course after making sure that you had old_commit (the first time push happens to a new ref you would not have that one). -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Removing deleted files after checkout
On Tue, 23 Aug 2005, Carl Baldwin wrote: The thing that this doesn't do is remove empty directories when the last file is deleted. I once expressed the opinion in a previous thread that directories should be added and removed explicitly in git. (Thus allowing an empty directory to be added). If this were to happen then this case would get handled correctly. However, if git stays with the status quo then I think that git-read-tree -u should be changed to remove the empty directory. This would make it consistent. I think that git-read-tree -u ought to remove a directory if it removes the last file (or directory) in it. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
baffled again
So I have another anomaly in my GIT tree. A patch to
back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
in my release branch at commit
62d75f3753647656323b0365faa43fc1a8f7be97
appears to have been lost when I merged the release branch to
the test branch at commit
0c3e091838f02c537ccab3b6e8180091080f7df2
So now this file still has this:
/* SSC_WAIT_COMPLETION appears to want this large alignment. gcc 4
* seems to give it by default, however gcc 4 is smarter and may
* not.
*/
struct disk_stat {
int fd;
unsigned count;
} __attribute__ ((aligned (16)));
in the test branch, when I think the comment and __attribute__
should have been backout out.
-Tony
Tree is at rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce reset type flag to git reset
At Tue, 23 Aug 2005 15:08:44 -0700, Junio C Hamano wrote: Sam Ravnborg [EMAIL PROTECTED] writes: But --soft, --hard looks rather confusing to me. Something like --force or --prune may be a bit more intuitive, and let default behaviour be the one you name --soft for now. I do not have objections to removing --mixed, but I do not find --force/--prune any less confusing than --soft/--hard. Its just a terminology so once people get used to it anything would do. But I agree that we need to come up with a good name for them. I do not think --force/--prune is it, though. I think the point is what is the target?. I believe git reset is targeting at the index file and only the index file and nothing more. it's that simple. what we want instead is a command to sync/reset/revert both index and tree to know working point. so this isn't core plumbing but as a user of git, i'm sure it's very handy to have it. --soft one is simple to think, so i'm starting with this one. let's assume that, as you described in the original post, this one is intended to be used to rework on the work _you_ have before. that means that _you_ know exactly what you are doing. there might be a case, and this happned to me quite some time when I was working with quilt, which you don't want to automatically add all the files you added on the privious commit. ie. moving defines from header to .c, splitting a work to two commits. so in this case, it's ideal to just use git reset if the command lists files removed from the index. for --hard option, what you want to do is to completely revert the current state of your index file and work tree to known point. for that, how about git-revert-script? can we add --force option to that command so that even if your working tree is dirty it reverts to the specified point? -- yashi - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix silly pathspec bug in git-ls-files
The verify_pathspec() function doesn't test for ending NUL character in the pathspec, causing some really funky and unexpected behaviour. It just happened to work in the cases I had tested. Signed-off-by: Linus Torvalds [EMAIL PROTECTED] --- diff --git a/ls-files.c b/ls-files.c --- a/ls-files.c +++ b/ls-files.c @@ -496,7 +496,7 @@ static void verify_pathspec(void) char c = n[i]; if (prev prev[i] != c) break; - if (c == '*' || c == '?') + if (!c || c == '*' || c == '?') break; if (c == '/') len = i+1; - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce reset type flag to git reset
Yasushi SHOJI [EMAIL PROTECTED] writes: for --hard option, what you want to do is to completely revert the current state of your index file and work tree to known point. for that, how about git-revert-script? git revert is to create a commit that reverts a previous commit, which I think is quite different from what we have been discussing so far. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
Catalin Marinas [EMAIL PROTECTED] writes: What's the definition of a parent in GIT terms? What are the restriction for a commit object to be a parent? Can a parent be an arbitrarily chosen commit? Yes it can. GIT does not care if the commit ancestry does not make sense in contents terms (i.e. you can record one tree object in a commit object, and record another, completely unrelated tree object in a commit object that has the first commit object as its parent). The git-diff-tree output from comparing those two commits may not make _any_ sense at all to the human, though, but that is not a problem for GIT to do its work. That's what I've been thinking. StGIT currently only implements the external view. An StGIT patch is a represented by a top and bottom commit objects. The bottom one is the same as the parent of the top commit. The patch is the diff between the top's tree id and the bottom's tree id. Jan's proposal is to allow a freeze command to save the current top hash and later be used as a second parent for the newly generated top. The problem I see with this approach is that (even for the internal view you described) the newly generated top will have two parents, new-bottom and old-top, but only the diff between new-top and new-bottom is meaningful. The diff between new-top and old-top (as a parent-child relation) wouldn't contain anything relevant to the patch but all the new changes to the base of the stack. Is the above an acceptable usage of the GIT DAG structure? Surely, as long as it stays internal as StGIT patch stacks. Even when it is exported (i.e. you manage to have other non StGIT managed tree to pull and merge with such a commit), the development history _might_ look funny and complicated, but it should not be a problem for GIT to handle. After all, you are doing complicated thing in the StGIT patch stacks when you pop, push and freeze number of times, so your history is complicated. If you want to record that history at least for StGIT internal bookkeeping purposes, GIT should not prevent you from doing it. Having said that, I would 100% agree with you that having a cleansed external view would be a good idea. It makes merging with StGIT managed repositories much more acceptable to ordinary GIT managed history. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Automatic merge failed, fix up by hand
On Tue, 2005-08-23 at 19:58 -0400, Junio C Hamano wrote: Len Brown [EMAIL PROTECTED] writes: I could get to 81065e2f415af6... commit (Linus tip at this moment), so if you can tell me where to snarf the other commit (702c7e76) that would help me diagnose the problem a lot. rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/to-akpm.git Thanks. I think merge-base, even though we attempted to fix it recently, is still confused and that is one of the reasons why you are getting this. prompt$ git-rev-parse origin test-lenb-merge 81065e2f415af6c028eac13f481fb9e60a0b487b 702c7e7626deeabb057b6f529167b65ec2eefbdb prompt$ git-merge-base origin test-lenb-merge 30e332f3307e9f7718490a706e5ce99f0d3a7b26 prompt$ git show-branch origin test-lenb-merge ! [origin] zd1201 kmalloc size fix * [test-lenb-merge] [ACPI] fix ia64 build issues resulting from L... -- + [origin] zd1201 kmalloc size fix + [origin~1] md: make sure resync gets started when array starts. + [origin~2] preempt race in getppid + [origin~3] Merge master.kernel.org:/pub/scm/linux/kernel/git/da -- 8 -- snip -- 8 -- + Merge ../to-linus-stable/ ++ [ACPI] re-enable platform-specific hotkey drivers by default + ARM: 2851/1: Fix NWFPE extended precision exception handling ++ [origin~34] intelfb/fbdev: Save info-flags in a local variable prompt$ git-rev-parse origin~34 3edea4833a1efcd43e1dff082bc8001fdfe74b34 Notice that show-branch, which walks the commit ancestry chain pretty much the same way merge-base does, notices and stops at origin~34 (that's 34th generation first parent commit from Linus tip) that is the common commit between the two heads being merged? And that commit, 3edea48... is different from what merge-base is reporting. If I maually run merge-cache using origin~34 as the merge base, only the following two files needs to result in non-simple merge: Documentation/acpi-hotkey.txt drivers/acpi/osl.c Do these two files match your expectation? No, I don't think so. Unless I missed something, to-akpm should be a proper super-set of from-linus, so I wouldn't expect a merge on these two. I'll take a look at merge-base.c next, but just in case I CC:ed this to Linus, who is more familiar with that code. thanks, -Len - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Automatic merge failed, fix up by hand
Junio C Hamano [EMAIL PROTECTED] writes: I think merge-base, even though we attempted to fix it recently, is still confused and that is one of the reasons why you are getting this. prompt$ git-rev-parse origin test-lenb-merge 81065e2f415af6c028eac13f481fb9e60a0b487b 702c7e7626deeabb057b6f529167b65ec2eefbdb --8-- snip --8-- + Merge ../to-linus-stable/ ++ [ACPI] re-enable platform-specific hotkey drivers by default + ARM: 2851/1: Fix NWFPE extended precision exception handling ++ [origin~34] intelfb/fbdev: Save info-flags in a local variable prompt$ git-rev-parse origin~34 3edea4833a1efcd43e1dff082bc8001fdfe74b34 I spoke too fast. merge-base is not giving you an incorrect answer. It just happens that the answer was way suboptimal. The [ACPI] re-enable platform-specific hotkey is what it chose, and my monkey guessing origin~34 happened to be better merge base, but the logic used by merge-base is to pick the latest (from wallclock wise) commit among several candidates, and by that criteria it did the right thing. In this case, the right thing was a wrong decision. So we probably should revisit how we choose the best merge base among candidates. I think origin~34 which happened to be the last one output by git show-branch was just an accident, not a good rule to follow, so changing merge-base to use the one that the other command shows the last would not be a good way to fix this. Probably the ideal way would be to give merge-base an option to spit out all the candidates, and have the script try to see which ones yield the least number of non-trivial merges. Linus? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Automatic merge failed, fix up by hand
On Tue, 23 Aug 2005, Len Brown wrote: I'm having trouble using git for merging kernel trees. git seems to manufacture conflicts in files that I never touched, and on some files it completely throws up its arms, see Not handling case below. Cool. You've found a case where git-merge-base finds what appears to be two equally good merge candidates, but they really aren't. The merge candidates are 30e332f3307e9f7718490a706e5ce99f0d3a7b26 and 3edea4833a1efcd43e1dff082bc8001fdfe74b34. To see this graphically, do: echo 30e332f3307e9f7718490a706e5ce99f0d3a7b26 .git/refs/tags/selected-merge-base echo 3edea4833a1efcd43e1dff082bc8001fdfe74b34 .git/refs/tags/other-merge-base echo 81065e2f415af6c028eac13f481fb9e60a0b487b .git/refs/tags/linus-head echo 702c7e7626deeabb057b6f529167b65ec2eefbdb .git/refs/tags/lenb-head gitk --all and notice how the not-selected one is: Author: Antonino A. Daplas [EMAIL PROTECTED] 2005-08-15 06:29:11 Committer: Linus Torvalds [EMAIL PROTECTED] 2005-08-15 09:59:39 Tags: not-selected while the selected on is: Author: Luming Yu [EMAIL PROTECTED] 2005-08-11 21:31:00 Committer: Len Brown [EMAIL PROTECTED] 2005-08-15 12:46:58 Tags: selected and the reason we chose that one is that it's three hours later than the other one, and we don't know any better. Not clear how I got into this state -- probably something to do with adding commits on branches and them git-pull-branch'ing them into the master; combined with updating the master from-linus. No, it's git. Well, it's git, together with your propensity to merge old work, which causes this kind of confusion where there are two equally good points to choose from as the merge base, and git chose the wrong one because it _looked_ newer and there was a recent merge to an old version of my tree. Cross-merges cause this, but I'm sure there's a good algorithm for selecting _which_ of the two interesting commits to pick. Give me a moment to think about this. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Automatic merge failed, fix up by hand
Junio C Hamano [EMAIL PROTECTED] writes:
Probably the ideal way would be to give merge-base an option to
spit out all the candidates, and have the script try to see
which ones yield the least number of non-trivial merges.
I first checked out your 702c7e.. commit, and slurped Linus tip
(back then, 81065e2f415af6c028eac13f481fb9e60a0b487b). Then I
ran git resolve with the attached patch (against the tip of
git.git master branch). Here is what happened, which seems to
work a little bit better, at least to me.
prompt$ git checkout -f
prompt$ git status
nothing to commit
prompt$ ls -l .git/HEAD
lrwxrwxrwx 1 junio src 26 Aug 23 15:43 .git/HEAD - refs/heads/lenb
prompt$ git resolve HEAD origin 'Merge Linus into Lenb'
Trying to find the optimum merge base
Trying to merge 81065e2f415af6c028eac13f481fb9e60a0b487b into
702c7e7626deeabb057b6f529167b65ec2eefbdb using
3edea4833a1efcd43e1dff082bc8001fdfe74b34
Simple merge failed, trying Automatic merge
Auto-merging Documentation/acpi-hotkey.txt.
merge: warning: conflicts during merge
ERROR: Merge conflict in Documentation/acpi-hotkey.txt.
Auto-merging drivers/acpi/osl.c.
fatal: merge program failed
Automatic merge failed, fix up by hand
Only lightly tested, in the sense that I did only this one case
and nothing else. For a large repository and with complex
merges, merge-base -a _might_ end up reporting many
candidates, in which case the pre-merge step to figure out the
best merge base may turn out to be disastrously slow. I dunno.
---
git diff HEAD
diff --git a/git-resolve-script b/git-resolve-script
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -49,7 +49,42 @@ if [ $common == $head ]; then
dropheads
exit 0
fi
-echo Trying to merge $merge into $head
+
+# Find optimum merge base if there are more than one candidate.
+LF='
+'
+common=$(git-merge-base -a $head $merge)
+case $common in
+?*$LF?*)
+ echo Trying to find the optimum merge base
+ G=.tmp-index$$
+ best=
+ best_cnt=-1
+ for c in $common
+ do
+ rm -f $G
+ GIT_INDEX_FILE=$G git-read-tree -m $c $head $merge \
+ 2/dev/null || continue
+ if GIT_INDEX_FILE=$G git-write-tree 2/dev/null
+ then
+ # This one results in just a Simple merge;
+ # It cannot become better than this.
+ best=$c
+ break
+ fi
+ # Otherwise, count the paths that are unmerged.
+ cnt=`GIT_INDEX_FILE=$G git-ls-files --unmerged | wc -l`
+ if test $best_cnt -le 0 -o $cnt -le $best_cnt
+ then
+ best=$c
+ best_cnt=$cnt
+ fi
+ done
+ rm -f $G
+ common=$best
+esac
+
+echo Trying to merge $merge into $head using $common
git-read-tree -u -m $common $head $merge || exit 1
result_tree=$(git-write-tree 2 /dev/null)
if [ $? -ne 0 ]; then
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -82,13 +82,17 @@ static struct commit *interesting(struct
* commit B.
*/
-static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
+static int show_all = 0;
+
+static int merge_base(struct commit *rev1, struct commit *rev2)
{
struct commit_list *list = NULL;
struct commit_list *result = NULL;
- if (rev1 == rev2)
- return rev1;
+ if (rev1 == rev2) {
+ printf(%s\n, sha1_to_hex(rev1-object.sha1));
+ return 0;
+ }
parse_commit(rev1);
parse_commit(rev2);
@@ -108,7 +112,7 @@ static struct commit *common_ancestor(st
if (flags == 3) {
insert_by_date(commit, result);
- /* Mark children of a found merge uninteresting */
+ /* Mark parents of a found merge uninteresting */
flags |= UNINTERESTING;
}
parents = commit-parents;
@@ -122,26 +126,46 @@ static struct commit *common_ancestor(st
insert_by_date(p, list);
}
}
- return interesting(result);
+
+ if (!result)
+ return 1;
+
+ while (result) {
+ struct commit *commit = result-item;
+ result = result-next;
+ if (commit-object.flags UNINTERESTING)
+ continue;
+ printf(%s\n, sha1_to_hex(commit-object.sha1));
+ if (!show_all)
+ return 0;
+ commit-object.flags |= UNINTERESTING;
+ }
+ return 0;
}
+static const char merge_base_usage[] =
+git-merge-base [--all] commit-id commit-id;
+
int main(int argc, char **argv)
{
- struct commit *rev1, *rev2, *ret;
+ struct commit *rev1, *rev2;
Re: Automatic merge failed, fix up by hand
On Tue, 2005-08-23 at 21:07 -0400, Junio C Hamano wrote: Junio C Hamano [EMAIL PROTECTED] writes: Probably the ideal way would be to give merge-base an option to spit out all the candidates, and have the script try to see which ones yield the least number of non-trivial merges. I first checked out your 702c7e.. commit, and slurped Linus tip (back then, 81065e2f415af6c028eac13f481fb9e60a0b487b). Then I ran git resolve with the attached patch (against the tip of git.git master branch). Here is what happened, which seems to work a little bit better, at least to me. prompt$ git checkout -f prompt$ git status nothing to commit prompt$ ls -l .git/HEAD lrwxrwxrwx 1 junio src 26 Aug 23 15:43 .git/HEAD - refs/heads/lenb prompt$ git resolve HEAD origin 'Merge Linus into Lenb' Trying to find the optimum merge base Trying to merge 81065e2f415af6c028eac13f481fb9e60a0b487b into 702c7e7626deeabb057b6f529167b65ec2eefbdb using 3edea4833a1efcd43e1dff082bc8001fdfe74b34 Looking at gitk, it certainly chose the right ancestor in this case. Simple merge failed, trying Automatic merge Auto-merging Documentation/acpi-hotkey.txt. merge: warning: conflicts during merge ERROR: Merge conflict in Documentation/acpi-hotkey.txt. Auto-merging drivers/acpi/osl.c. fatal: merge program failed Automatic merge failed, fix up by hand Only lightly tested, in the sense that I did only this one case and nothing else. For a large repository and with complex merges, merge-base -a _might_ end up reporting many candidates, in which case the pre-merge step to figure out the best merge base may turn out to be disastrously slow. I dunno. It ran a heck of a lot faster than the alternative -- which would have been to export 85 patches and re-commit them to a new tree. Perhaps Tony's recent merge mystery had the same cause and he can also benefit from this patch? thanks! -Len - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix git-rev-parse breakage
The --flags cleanup caused problems: we used to depend on the fact that
revs_only magically suppressed flags, adn that assumption was broken by
the recent fixes.
It wasn't a good assumption in the first place, so instead of
re-introducing it, let's just get rid of it.
This makes --revs-only imply --no-flags.
[ Side note: we might want to get rid of these confusing two-way flags,
where some flags say only print xxx, and others say don't print yyy.
We'd be better off with just three flags that say print zzz, where zzz
is one of flags, revs, norevs ]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -160,6 +160,7 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, --revs-only)) {
revs_only = 1;
+ no_flags = 1;
continue;
}
if (!strcmp(arg, --no-revs)) {
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Automatic merge failed, fix up by hand
On Tue, 23 Aug 2005, Junio C Hamano wrote: Only lightly tested, in the sense that I did only this one case and nothing else. For a large repository and with complex merges, merge-base -a _might_ end up reporting many candidates, in which case the pre-merge step to figure out the best merge base may turn out to be disastrously slow. I dunno. I think it's the right thing to do for now (and what I was going to suggest), and if people find it too slow, we can consider teaching read-tree to take multiple common ancestors and use any of them that gives clear result on a per-file basis. On the other hand, Tony might have hit a bad case with an ill-chosen common ancestor for a patch/revert sequence, and we probably want to look into that if we've got some history that demonstrates the problem. I think that, if there are two common ancestors, one of which has applied a patch and one of which hasn't, and on one side of the merge it gets reverted, we should get the revert, but we'll only get it if we choose the ancestor where it was applied. (Letters are versions of the file, which 'b' being the bad patch; the second column is the two choices for common ancestor) a-b-a-? / X / a-b-b-b Of course, you could have the two lines exactly flipped for a different file in the same commits, or for a different hunk in the same file, and there would be no single choice that doesn't lose the revert. The really right thing to do is identify that there is a b-a transition that is not a trivial merge and that is not beyond a common ancestor, but that's hard to determine easily and with sufficient granularity to catch everything. I still someday want to do a version of diff/merge for git that could select common ancestors on a per-hunk basis and identify block moves and avoid giving confusing (but marginally shorter) diffs, but that's a major undertaking that I don't have time for right now. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix git-rev-parse breakage
Linus Torvalds [EMAIL PROTECTED] writes: This makes --revs-only imply --no-flags. [ Side note: we might want to get rid of these confusing two-way flags, where some flags say only print xxx, and others say don't print yyy. We'd be better off with just three flags that say print zzz, where zzz is one of flags, revs, norevs ] I suspect that would not fly too well. Being able to say give me all flags meant for rev-list, give me all what are meant for rev-list, and give me all non-flags that are meant for rev-list are very handy, so I'd rather want to see --revs-only to mean meant for rev-list, --no-revs to mean not meant for rev-list, --flags to mean only ones that start with a '-', and --no-flags to mean only ones that do not start with a '-'. And that would give me (rev/no-rev/lack thereof) x (flag/no-flag/lack thereof) = 9 combinations. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
I'm at home, and too lazy to log in to work to look at my tree. But I have a theory as to what went wrong for me. At the start I had a file, same contents in test and release branch. I applied a patch to release, and pulled to test. So the contents are still the same, both with the patch applied. Next, I was given a better patch (the first one just masked the real problem and happened to make the symptoms go away). This patch touches a completely different file. So I applied a patch to revert the change in release, and the new patch. Now ... when I try to merge release into test, my guess is that GIT is looking at the common ancestor before I touched anything. So when it compares the current state of this file it sees that I have the bad patch in the test tree, and the release tree has the original version (which has had the patch applied and reverted ... so the contents are back at the original state). So GIT decides that the test branch has had a patch, and the release branch hasn't ... and so it merges by keeping the version in test. Plausible? -Tony - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
On Tue, 23 Aug 2005, Tony Luck wrote: So GIT decides that the test branch has had a patch, and the release branch hasn't ... and so it merges by keeping the version in test. Plausible? Very. Sounds like what happened. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
