From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261858AbUKCTs3@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261858AbUKCTs3 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 3 Nov 2004 14:48:29 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261785AbUKCTrU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 3 Nov 2004 14:47:20 -0500
Received: from mx1.redhat.com ([66.187.233.31]:49320 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S261858AbUKCTqv (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Nov 2004 14:46:51 -0500
From: David Howells <dhowells@redhat.com>
In-Reply-To: <20041102234610.GB7040@lst.de> 
References: <20041102234610.GB7040@lst.de>  <76b4a884-2c3c-11d9-91a1-0002b3163499@redhat.com> 
To: uClinux development list <uclinux-dev@uclinux.org>
Cc: akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [uClinux-dev] [PATCH 1/14] FRV: Fujitsu FR-V CPU arch implementation 
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 03 Nov 2004 19:46:36 +0000
Message-ID: <8632.1099511196@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


> please don't copy the horrible boot decompressor cludges to new arches.
> Why can't your loader support vmlinux.gz files for a new port?

You're assuming I've control over the bootloader.

> Please use the generic kernel/irq/* code.

That code is not sufficient.

> I can't see this beeing called from generic code ever, why do you
> implement it?

It's a placeholder for something I'd like to implement for the FR451 CPU which
has a decrementer counter. It is actually called from entry.S.

> > +void *dma_alloc_coherent(struct device *hwdev, size_t size, dma_addr_t *dma_handle, int flag)

> the last argument is the gfp mask.

It's called "flag" in include/asm-i386/dma-mapping.h. And shouldn't it be an
"unsigned long" if it's GFP flags?

> does GFP_DMA really hae the same meaning as on i386 here?

I'm not sure whether it should put all of its memory in the DMA region, or
none of it. There's no documentation on this.

> Don't mess with per-arch fields in common procfs files.

Should I then add an arch-specific file to "/proc/<pid>/"?

David