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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/