Re: How to test and debug Dragonfly BSD?

["<Marcin Ropa>" <marcinropa@xxxxxxxxx>]

Thanks Alex for your description. I've found it useful for my 'code
digging'. Now I have to only spend many (probably) weeks :) to
understand what is going on in sources. If I run into another problem
i will try catch you (and others) on dfbsd's irc channel.

Greetings
Marcin

2010/11/9 Alex Hornung <ahornung@gmail.com>:
> On 09/11/2010 05:31, <Marcin Ropa> wrote:
>>
>> There are tons of code. Is there any README, describing which
>> functionality I may expected in which subdirectory? Where is core of
>> the system, where main structures are initialized and everything
>> begins when the system starting.
>
> Just take a look at the directory structure in the source tree, I think it's
> pretty obvious how things fit together. (Almost) every top level directory
> in userland has a name that corresponds to its name on the destination
> installation, e.g. usr.bin is the stuff that goes into /usr/bin. Some
> notable exceptions are:
> contrib -> which is contributed (3rd party) code. The Makefiles are still in
> the normal directories (i.e. sbin)  but the sources for these are here
> gnu -> contains the the Makefiles for gnu-licensed programs (the code
> resides in contrib)
> crypto -> contains sources that are of restricted exportability, at least
> historically.
> nrelease -> contains stuff to build ISOs and IMGs
> tools -> contains useful stuff like our git template, iirc
> test -> contains all sorts of random junk, including test cases, small
> scripts, files for test commits, ...
> and finally:
> sys -> Contains the kernel and bootloader code
>
> In sys the most important directories that you should know about are,
> kern -> main kernel functionality
> sys -> main kernel include files
> dev -> contains all sorts of device drivers, nicely categorized in the
> subfolders
> net -> Contains network related stuff (but not hardware drivers)
> platform -> platform/architecture dependent code that is not portable
> bus -> Contains PCI, ISA and CAM (maybe you know it from FreeBSD, maybe not;
> it's a neat abstraction layer for SCSI stuff, for example, above the HBAs)
>
> For more help, just ask on the IRC.
>
> Hope this helps,
> Alex Hornung
>
>
>
>