Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jun 2001 12:18:53 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        arch@FreeBSD.org
Subject:   Re: sysorg: sys/contrib
Message-ID:  <XFMail.010614121853.jhb@FreeBSD.org>
In-Reply-To: <20010614210425.A86414@sunbay.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 14-Jun-01 Ruslan Ermilov wrote:
> On Thu, Jun 14, 2001 at 10:48:07AM -0700, John Baldwin wrote:
>> 
>> On 14-Jun-01 Jonathan Lemon wrote:
>> > On Thu, Jun 14, 2001 at 01:07:54PM +0300, Ruslan Ermilov wrote:
>> >> Hi!
>> >> 
>> >> There are some problems with the current location of IPFilter sources.
>> >> 
>> >> 1.  The idea of http://people.freebsd.org/~jhb/docs/sysorg.txt was
>> >>     that src/sys/contrib/ mirrors the structure of src/sys/; this is
>> >>     currently broken.  src/sys/contrib/ipfilter/netinet/ should have
>> >>     been actually called the src/sys/contrib/netinet/.
>> > 
>> > I'm ambivalent on this.  On one hand, having the additional directory
>> > level nicely categorizes the nature of the sys/contrib bits in the same
>> > sense that /src/contrib does, and makes it easier to remove.  OTOH, 
>> > this might get messy at some point.
>> 
>> I can see the value in contrib/ipfilter.  sysorg.txt is not set in stone. :)
>> For 3rd party software, it is better if we let the software keep it's
>> distributed layout.  The intention was that if you had device driver xyz,
>> then
>> it's sources would be in sys/contrib/dev/xyz/ and under that subdirectory it
>> would follow the internal layout of the package.  If we had a networking
>> subdirectory, then sys/contrib/net/ipfilter would be the way to go, but
>> since
>> networking all lives at the top level, sys/contrib/ipfilter is probably
>> fine.
>> Thus, some examples that might help illustrate:
>> 
>>         sys/contrib/fs/my_spiffs_fs/
>>         sys/contrib/dev/my_spiffy_device_driver/
>>         sys/contrib/vm/my_spiffy_vm_pager/
>>         sys/contrib/my_spiffy_networking_code/
>>         sys/contrib/my_spiffy_kernel_debugger/
>>         sys/contrib/compat/3rd_party_foo_os_emulation/
>>         sys/contrib/lib/my_spiffy_kernel_library/
>>         sys/contrib/boot/my_spiffy_boot_loader/
>> 
> Hmm, clumsy.  What if contributed piece FOO has fs/ and lib/ parts?
> Should they be sys/contrib/FOO/fs/ and sys/contrib/FOO/lib/ or
> sys/contrib/fs/FOO/ and sys/contrib/lib/FOO/?

sys/contrib/FOO/.  The main goal with 3rd party software is keeping it together
in its distributed format.  If things don't compartamentalize well, then it may
fall back to a src/contrib/ type deal where it's just sys/contrib/FOO for
everything.  However, thus far 3rd party _kernel_ software has usually only
been in one category.

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010614121853.jhb>