[U-Boot] [PATCH v2 0/6] Clean up top-level directory structure

[Peter Tyser]

Hi Rafal,

> > I like the Linux and u-boot-v2 directory layout too the more I think
> > about it too.  How about if I resend this series but with the final
> > directory structure looking like:
> >
> > /arch/$(ARCH)/lib/<source files currently in lib_$(ARCH)
> >
> > /lib/
> > 	/<source files currently in lib_generic>
> > 	/libfdt/
> > 	/lzma/
> > 	/lzo/
> >
> > /examples/
> > 	/api/
> > 	/standalone/
> 
> Not directly answering your question, but rather a minor naming nit:  
> strictly speaking the 'api' subdir contents are also standalone  
> applications... so the above naming scheme is not clear cut, although  
> I don't have much better suggestions :-) The 'standalone' above use  
> the legacy jumptable calls method, so maybe 'jumptable' dirname would  
> work? Other thoughts?

I see your point.  <nitpick>Its a bit confusing as U-Boot documentation
seems to refer to "Standalone applications" alot, and in general that
documentation is specifically referring jumptable applications.  eg
"doc/README.standalone" and "Standalone HOWTO" in README.  If you dig
you can find the API applications mentioned in api/README - I don't see
it referenced much in either the standard location of /doc/* or /README.
I guess my only point is that it would be great if the application
documentation was consistent between the jumptable and API method, then
it would be a a no brainer as far as naming /examples directory layout.
As is, documentation implies "standalone application" means jumptable
application.</nitpick>

In any case, I'm OK with a different directory layout.  /examples/[api|
jumptable] is fine, or we could even add an apps subdir,
eg: /examples/apps/[api|jumptable].  I'm also fine with leaving it the
way I had it initially as all documentation currently implies standalone
== jumptable, api = API method.

Let me know if you or others have arguments for 1 convention over
another.

Thanks,
Peter