Proposal for reorg of kernel directory

Arnd Bergmann arnd at arndb.de
Wed Jun 22 05:25:03 EST 2005


On Dinsdag 21 Juni 2005 21:02, Becky Bruce wrote:

> We've recently begun work on a port of the 64-bit kernel to a
> Freescale part, and noticed that all the platform-specific code is
> currently in the kernel directory.  With new 64-bit parts in the
> works, we expect the number of supported platforms to increase
> significantly and to include more embedded systems.

Hmm, at least I'd hope not to need a new platform type for every
piece of hardware, so there would not be too many of these.

I would like to see platform types like 'everything with 64 bit
Freescale CPUs running on SLOF' and maybe another platform type
for the same CPU with a flat device tree if that differs a lot.

> Kernel directory:
> --------------------------
> binfmt_elf32.c
> ioctl32.c
> ptrace32.c
> signal32.c
> sys_ppc32.c

If you start creating new subdirectories, these would be a natural
choice for yet another directory. E.g. ia64 and x86_64 do that
as well.

> This next section lists out the files that appear to be specific
> to a particular platform.  I've separated them by platform for the
> sake of ease of parsing this list, but I would imagine that these
> would all end up in the high level "platforms" directory:
> 
> 
> pSeries:
> ---------------------

> rtas.c
> rtas_flash.c
> rtas-proc.c
> rtasd.c
> scanlog.c

Most of the rtas stuff is not really pSeries specific, so it
should either stay in kernel/ or go to a subdirectory of it
if you insist. The BPA patches that I'm currently making
also move some code around to have a better distinction between
pSeries specific code and generic rtas code that is also
used by BPA and possibly other platforms using SLOF.

> And the files that I believe should go into syslib:
> 
> syslib/
> -----------
> btext.c
> i8259.c
> i8259.h
> mpic.c
> mpic.h
> nvram.c
> of_device.c
> prom.c
> prom_init.c
> rtc.c
> u3_iommu.c
> udbg.c
> vio.c
> viopath.c (? - not clear on this one)	

I don't really see the point in this directory. Why not just
leave these files in kernel/?

	Arnd <><



More information about the Linuxppc64-dev mailing list