RE: cmdline.c file name collision

Hicks, Jamey
2002-11-14T22:08:38Z

I think we should change the filename to avoid the collision in 2.4.x kernels. I do not think we should do surgery on the CVS repository even though that means the file history gets split. I've renamed my copy to cmdlinepart.c in the handhelds.org CVS repository, but I have not done so on the MTD repository. If no one objects, I will add cmdlinepart.c and remove cmdline.c in the infradead cvs.

Jamey

> -----Original Message-----
> From: Scott Anderson [mailto:scott_anderson@mvista.com]
> Sent: Wednesday, November 13, 2002 2:32 PM
> To: Hicks, Jamey
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: cmdline.c file name collision
>
>
> "Hicks, Jamey" wrote:
> > hmm. My first thought was to rename drivers/mtd/cmdline.c to
> > drivers/mtd/mtdcmdline.c or drivers/mtd/cmdlinepart.c.
>
> That sounds reasonable. Does someone that has direct access
> to the CVS
> repository want to move the files around in the repository
> (so we don't
> lose history) or should I just submit a patch that removes
> the file and
> adds the file back with a different name?
>
> > Actually, that was my second thought. My first thought was
> to wonder
> > why CONFIG_MODVERSIONS flattens the kernel source file namespace.
> > I just turned on CONFIG_MODVERSIONS to build an ipaq
> kernel, and I find
> > I also have a name conflict on arch/arm/mach-sa1100/pm.c
> and kernel/pm.c.
>
> I've been told third hand or so that it is a "known
> limitation" in 2.4.
> I just looked in 2.5, and this limitation has been eliminated
> (there is
> a hierarchy of files under include/linux/modules that parallels the
> source hierarchy).
>
> With that new found information, I guess a new question comes up: does
> working around the 2.4 limitation warrant the rename when the
> limitation
> is removed in 2.5?
>
> Scott Anderson
> scott_anderson@mvista.com MontaVista Software Inc.
> (408)328-9214 1237 East Arques Ave.
> http://www.mvista.com Sunnyvale, CA 94085
>