David Young wrote:
> I would like to rearrange our Atheros HAL sources in sys/contrib/ to
> ease HAL importation from FreeBSD and madwifi.org.  Here is the new
> arrangement that I propose:
> 
>         sys/contrib/dev/ath/
>                 COPYRIGHT README ah_desc.h freebsd version.h ah.h
>                 ah_devid.h public
>         sys/contrib/dev/ath/netbsd/             OS "glue"
>                 ah_if.m ah_osdep.c ah_osdep.h
>         sys/contrib/dev/ath/public/             OS-independent binaries
>                 arm9-le-thumb-elf.hal.o.uu arm9-le-thumb-elf.inc
>                 arm9-le-thumb-elf.opt_ah.h
>                 ... HALs ...
>                 xscale-le-elf.hal.o.uu xscale-le-elf.inc
>                 xscale-le-elf.opt_ah.h
> 
> This will ease updates by myself and by other developers.  I believe
> we will get more frequent HAL updates following this rearrangement,
> both by reducing the work and increasing in manpower.

I'm not certain but I believe this layout means one can do a straight 
cvs import from the hal release--is that correct?  If so I'm all for it.

> 
> Just a few facts that may quiet a few objections before they start:
> 
>         This is not a settled or imminent change.  I may not make
>             the change myself, since I'm "purty durned busy."
> 
>         I am responsible for the present arrangement of the sources,
>             which was designed, for better or for worse, to parallel
>             the sys/ hierarchy.
> 
>         With the current arrangement, importing HALs is more work and
>             more error-prone than with the FreeBSD/Linux arrangement,
>             but there is enough of a hump that it does not happen as
>             often and as quickly as we would like, moreover,
> 
>         the additional work will be mine and a couple of others'; in
>             all likelihood, it will not be your work.

I've been hounding David for a while about this so blame me.  What I've 
been asking for is that what is imported under contrib on the vendor 
branch be identical to what comes out of the vendor's depot.  This makes 
it possible to directly diff stuff and also to do straight cvs import's. 
  There has always been a question of where contrib/dev/ath/netbsd goes 
(the glue code between the os and the hal).  It is in the hal area 
because when things were first done these files were needed to build an 
os-specific hal; but now the hal is built w/o os dependencies so if 
desired the files could be moved over to where the driver is (or not).

	Sam