linux-kernel - Re: [GIT PULL] sh updates for 2.6.35-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 May 2010 16:21:37 +0530
From:	Jaswinder Singh Rajput <jaswinderlinux@...il.com>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org,
	magnus.damm@...il.com,
	Russell King - ARM Linux <linux@....linux.org.uk>
Subject: Re: [GIT PULL] sh updates for 2.6.35-rc1

Hello Paul,

On Tue, May 18, 2010 at 3:45 PM, Paul Mundt <lethal@...ux-sh.org> wrote:
> On Tue, May 18, 2010 at 03:15:31PM +0530, Jaswinder Singh Rajput wrote:
>> I have few doubts :
>>
>> 1. Which other architectures are using :
>> include/linux/sh_clk.h, include/linux/sh_dma.h and include/linux/sh_intc.h
>>
> ARM for starters, and there are likely to be others in the future, too.
> Grepping would have made this pretty apparent.
>
>> 2. If you think, in future some architecture will going to use these
>> files, then do you think sh_*.h name is appropriate.
>>
> Yes, given that they're all SH IP blocks. Although if there's many more
> of them then of course putting them in their own subdirectory is an
> option, too.
>
>> 3. Can we move :
>> include/linux/sh_clk.h -> drivers/sh/sh_clk.h
>> include/linux/sh_dma.h -> drivers/dma/sh_dma.h
>> include/linux/sh_intc.h -> drivers/sh/sh_intc.h
>> So that if someone want to use these file they can use it from here.
>>
> No.
>
> The alternative is creating a shared architecture directory, which
> doesn't really scale well given how these blocks can be arbitrarily
> reused across different architectures -- but it's still something we
> might have to look at depending on what else pops up that can't be
> cleanly shared through the current scheme. You're of course welcome to
> dig up the discussions in the archives when the ARM SH-Mobile code was
> introduced in the first place.
>

Hmm, so still it is between ARM and SH, so better option will be :

include/linux/sh_clk.h -> include/sh/clk.h
include/linux/sh_dma.h -> include/sh/dma.h
include/linux/sh_intc.h -> include/sh/intc.h

So when arm files will come then, then we can make it like this :

include/arm/clk.h
include/arm/dma.h
include/arm/intc.h

So user will program like this :

#include <arm/dma.h>
#include <sh/dma.h>


There are no doubts in future we will have asymmetrical processing,
where we will use multiple architectures, so better make different
directory for them instead of putting load on include/linux which
already over-loaded.

Thanks,
--
Jaswinder Singh.
--
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/