[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <49E57E05.60400@petalogix.com>
Date: Wed, 15 Apr 2009 08:26:13 +0200
From: Michal Simek <michal.simek@...alogix.com>
To: David Miller <davem@...emloft.net>
CC: arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: struct exception_table_entry
David Miller wrote:
> From: Arnd Bergmann <arnd@...db.de>
> Date: Tue, 14 Apr 2009 16:36:11 +0200
>
>
>> On Thursday 09 April 2009, Michal Simek wrote:
>>
>>
>>> I am doing some cleanup things in MB MMU kernel and I looked at
>>> exception_table_entry structure.
>>> Only alpha use different types among others. Some arch use only
>>> different names and types int/long.
>>> I think that this structure could be moved to any generic location ->
>>> asm-generic/uaccess.h folder.
>>>
>>> I think that this structure types should be acceptable for every archs?
>>>
>>> #ifndef exception_table_entry
>>> struct exception_table_entry {
>>> unsigned long insn;
>>> unsigned long fixup;
>>> };
>>> #endif
>>>
>>> What do you think?
>>>
>> Yes, sounds good to me. Have you tried using my generic version of
>> uaccess.h on microblaze? It already contains a definition like this,
>> though most of the header doesn't apply for MMU-based architectures.
>>
>> I suppose it can be improved a bit, but should do the basic job.
>>
>
> Note that for space saving several 64-bit architectures use plain
> "int" here when they know that all kernel addresses are in the low
> 32-bits of the address space.
>
Just one my note: use u32 instead of int.
Michal
> sparc64 is one such architecture and I'd prefer if the size of these
> tables does not bloat up when you guys try to make this thing generic.
>
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists