Proposal for reorg of kernel directory

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Jun 23 08:00:17 EST 2005


On Wed, 2005-06-22 at 14:36 -0500, Becky Bruce wrote:
> On Jun 21, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote:
> 
> >
> >> To prevent bloating the kernel directory, I'd like to propose a
> >> reorganization of the ppc64 tree to look more like the ppc tree.
> >> This includes the creation of  "platforms" and "syslib" directories
> >> that would contain platform-specific code and non-platform-specific
> >> system code, respectively.
> >
> > I'm not fan at all of kernel vs. syslib. Even on ppc32, and years after
> > the split, I still keep trying to get at files in the wrong directory 
> > ;)
> 
> I can't really say I'm a huge fan, either - I had to get Kumar to  
> explain to me the purpose of syslib.  However, looking at the 32-bit 
> side, there are quite a few files over there that would make the kernel 
> directory rather large if they were in one directory.  I think the idea 
> behind that organization was to have:
> 	- "kernel" dir - ppc generic kernel code and processor-specific code
> 	- "platforms" dir - platform-specific code
> 	-  "syslib" - all device/system-level kernel code that is not 
> platform-specific.
> 
> That said, I don't think the line between the 3 can be drawn perfectly 
> in practice, hence the confusion we have about where to find files.  I 
> think there's some merit in having the 3 directories, but if the 
> concensus of this group is that we only separate out the platform code, 
> that works for me.

I'd start by splitting only platform. We can do different kind of splits
in kernel. For example, we can have kernel32 with *32.c..

> OK, so let's talk about how the organization of platforms would look if 
> we go with the split.   As I see it, there are several options:
> 
> 1.  Slam all of the platform-specific files into a flat "platforms" 
> directory.

This is the ppc32 approach. I prefer subdirs but paulus doesn't ;)

> 2.  Do something similar to the 32-bit tree's implementation of the 
> platforms dir, where single-platform code is at the highest level in 
> "platforms".  Create subdirectories for platforms which are very 
> similar and share most of their code - I believe this ties in with 
> Arnd's idea about more generic platforms.

32 bits started with a flat platforms dir. Things like 4xx popped up
afterward afaik.

> 3.  Subdirs for each platform under the platforms directory.  I don't 
> really like this one, but it is an option.
> 
> With 1 and 2 also comes the issue of file naming - files that are truly 
> platform-specific should probably have the file name prefixed with the 
> platform name.  I believe this is mostly true today.

It is.

Ben.





More information about the Linuxppc64-dev mailing list