|
On Fri, Sep 19, 2008 at 2:00 AM, David Miller wrote:
> From: Simon Horman <horms@xxxxxxxxxxxx>
> Date: Fri, 19 Sep 2008 09:52:22 +1000
>
>> On Thu, Sep 18, 2008 at 10:04:28PM +0200, Julius Volz wrote:
>> > On Wed, Sep 17, 2008 at 10:14 PM, David Miller wrote:
>> > > From: Chris Snook <csnook@xxxxxxxxxx>
>> > > Date: Wed, 17 Sep 2008 14:37:33 -0400
>> > >
>> > >> Julius Volz wrote:
>> > >> > Since IPVS now does partial IPv6, should we finally move it from
>> > >> > "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
>> > >> > long time ago, but that was before any of the actual v6 features, so
>> > >> > there was probably no interest.
>> > >>
>> > >> Whatever the netfilter people want is fine with me.
>> > >
>> > > I think, especially in the long term, putting IPVS under net/netfilter/
>> > > is the right thing to do.
>> >
>> > Ok thanks, I'll send the patch for that once lvs-next-2.6 or
>> > net-next-2.6 builds for ARCH=um again (there seems to be some breakage
>> > at the moment)...
>>
>> Once net-next-2.6 is working again, let me know and I'll pull it
>> into lvs-next-2.6.
>
> I can't fix this if people don't tell me what the problem is.
Sorry, I sent this from an environment where I didn't have the
information and just wanted to give a quick ACK on the IPVS move
decision.
The build with ARCH=um seems to have a problem with the
architecture-specific headers:
net/core/skb_dma_map.c: In function 'skb_dma_map':
net/core/skb_dma_map.c:20: error: implicit declaration of function
'dma_mapping_error'
The bad commit that introduces the skb_dma_map.c file (and this error)
is a40c24a1336. Previous versions build fine.
> Is there some upstream fix and cures this and all I need to do is
> sync net-next-2.6 up with Linus's tree? Is there some external
> fix?
Linus' linux-2.6 (he doesn't have a linux-next-2.6, right?) works, but
that doesn't even contain the file that has the build problem.
> It's totally stupid to stall development because of an issue like this
> yet give no direction or diagnostics we can use as a path to resolve
> it.
Yes, I'll give a better report next time.
Julius
--
Julius Volz - Corporate Operations - SysOps
Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
