Re: [PATCH] make atomic_t volatile on all architectures

2007-08-11 Thread Linus Torvalds
On Sun, 12 Aug 2007, Segher Boessenkool wrote: > > Note that last line. Segher, how about you just accept that Linux uses gcc as per reality, and that sometimes the reality is different from your expectations? "+m" works. We use it. It's better than the alternatives. Pointing to stale documen

Re: [PATCH] make atomic_t volatile on all architectures

2007-08-11 Thread Segher Boessenkool
You'd have to use "+m". Yes, though I would use "=m" on the output list and "m" on the input list. The reason is that I've seen gcc fall on its face with an ICE on s390 due to "+m". The explanation I've got from our compiler people was quite esoteric, as far as I remember gcc splits "+m" to an i

[RFC: -mm patch] improve the SSB dependencies

2007-08-11 Thread Adrian Bunk
On Sat, Aug 11, 2007 at 04:42:39PM +0200, Michael Buesch wrote: > On Saturday 11 August 2007 16:30:02 Adrian Bunk wrote: > > And offering more options than required or manually sending users into > > other menus are bad thing for your users. > > Breaking compilations are as bad. > So, does your e

Re: Weird network problems with 2.6.23-rc2

2007-08-11 Thread Jiri Kosina
On Sat, 11 Aug 2007, Shish wrote: > Something seems to have broken in 2.6.23-rc2, and I'm not sure what, or > where I should look for further debugging. The info I have: > > On my 2.6.23-rc2 desktop, things run fine. > > On my test server, built from the same source tree, networking goes > stran

Re: [RFC] IP_RECVERRC

2007-08-11 Thread jamal
On Fri, 2007-10-08 at 18:26 +0200, Andi Kleen wrote: > Are we talking about TCP or UDP/RAW? Both. initially datagram. I think you gave me something to think about - let me go back to the drawing table. I like the per socket timer idea; however, if i can solve from the app (or write my own app w

Re: [PATCH] b44-ssb: Fix the SSB dependency hell

2007-08-11 Thread Michael Buesch
On Saturday 11 August 2007 16:30:02 Adrian Bunk wrote: > And offering more options than required or manually sending users into > other menus are bad thing for your users. Breaking compilations are as bad. So, does your example actually work in practice and not only in theory, too? My select stuf

Re: [PATCH] b44-ssb: Fix the SSB dependency hell

2007-08-11 Thread Adrian Bunk
On Sat, Aug 11, 2007 at 11:36:46AM +0200, Michael Buesch wrote: > > That's all a silly discussion, guys. > I personally do _not_ care which way we do this. > BUT: My users do care. There is currently no way telling them to first enable > SSB, when they want to select b44 (for example). The curren

Re: [PATCH] b44-ssb: Fix the SSB dependency hell

2007-08-11 Thread Michael Buesch
On Saturday 11 August 2007 03:41:11 Adrian Bunk wrote: > On Sat, Aug 11, 2007 at 02:57:36AM +0200, Johannes Berg wrote: > > On Sat, 2007-08-11 at 02:43 +0200, Adrian Bunk wrote: > > > > > -ENOMENUCONFIGPATCH > > > > Has anybody decided how it could possibly even look like anyhow? It > > should be

Re: [PATCH 6/24] make atomic_read() behave consistently on frv

2007-08-11 Thread David Howells
Chris Snook <[EMAIL PROTECTED]> wrote: > cpu_relax() contains a barrier, so it should do the right thing. For non-smp > architectures, I'm concerned about interacting with interrupt handlers. Some > drivers do use atomic_* operations. I'm not sure that actually answers my question. Why not smp

Re: RealTek 8169 support question

2007-08-11 Thread Francois Romieu
Chuck Lever <[EMAIL PROTECTED]> : [...] > Not yet. I wanted to check with "the Maintainer" to see if it was worth > trying. :-) The last time I tried a kernel build on one of these It is worth trying. > little Via processors, it took forever. Will give it a shot. Why can you not compile on