Re: RFC: rename arch/arm/mach-s3c2410 to arch/arm/mach-s3c24xx

[Bill Gatliff <bgat@billgatliff.com>]

Dimitry:

Dimitry Andric wrote:

>Ben Dooks wrote:
>  
>
>>With the advent of the s3c2410 port adding support for
>>more of the samsung SoC product line (s3c2440, s3c2442,
>>s3c2400) there have been several requests by other people
>>to rename the (in their opinion) increasingly inaccurate
>>arch/arm/mach-s3c2410 to arch/arm/mach-s3c24xx.
>>    
>>
>
>Well, if you start this way, you might also consider renaming it to
>mach-s3cxxxx, since Samsung also seems to have S3C3410, S3C44B0 and who
>knows what else.  Otherwise you'd maybe have to do such an operation
>again in the future...
>
>Also, I've always found the dichotomy of having
>"include/asm-arm/arch-s3c2410" and "arch/arm/mach-s3c2410" rather weird.
>Isn't s3cxxxx an "architecture", instead of a specific machine?  If so,
>arch/arm/arch-s3cxxxx would be more logical.
>  
>

I always interpreted the arch/arm directories to be "machines based on 
the s3cxxxx", etc.  Thus, in my world there's no dichotomy.  But hey, 
that's just one person's world.  :)

>Anyway, by starting to rename directories, you start a never-ending
>quest, and you'll stress the abilities of most version control systems
>too.  Your huge diff for just one rename operation already shows this.
>  
>

It doesn't stress GNU Arch, and I bet it doesn't stress SVN or Cogito.  
What it does do is make the kernel code appear more obvious and better 
organized, which I see as being a good thing for future 
maintainability's sake alone.  So I'm all for these changes.

>There are certainly a lot more directories (also not specifically
>arm-related ones) in the Linux kernel source that could be renamed to be
>more logical, but I'd say the cost is rather large.  E.g. difficulty
>merging patches on older kernels and other version control difficulties.
>  
>

Well, now's our chance to find out whose VC systems we break.  :)  And I 
don't see the "moving patches forward from older kernels" as being an 
argument for locking down the current/future state of the kernel sources.


Respectfully,


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com