Mercurial > illumos > illumos-gate
changeset 12780:c39281da15f8
1 Need README & TODO for Illumos project
Reviewed by: garrett@nexenta.com
Approved by: garrett@nexenta.com
author | Garrett D'Amore <garrett@nexenta.com> |
---|---|
date | Thu, 29 Jul 2010 16:07:59 -0700 |
parents | 96016f1d9837 |
children | c8da1d642945 |
files | README TODO |
diffstat | 2 files changed, 117 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/README Thu Jul 29 16:07:59 2010 -0700 @@ -0,0 +1,46 @@ +Illumos Gate README - July 29, 2010. + +This is the Illumos gate. It contains the following subdirectories: + + - usr/src -- this is a clone (with changes) of the Oracle ONNV gate. + We should avoid making too many disruptive changes here. It + will be periodically synced with ONNV. + + - usr/illumos -- this is the set of bits that we deliver, which are not + yet integrated into the onnv tree. This may include various + testing bits, etc. These bits (for whatever reason), are things + that we think are inappropriate for inclusion in the upstream and + really are specific to illumos. + +Integration Rules: + + All changes must have been reviewed, and (for the interim only!) + approved by the gatekeeper (below). A code review may be performed + by someone other than the gatekeeper, but the final integration should + still be approved by the gatekeeper. (Think CRT advocate for now.) + The gatekeeper will want to see your webrev and hg outgoing -v. + + All changes must adhere to typical ON style and quality rules. + For example, pass full cstyle, applicable lint rules, etc. + + All commits must include either a CDDL or BSD/MIT license, unless + approved otherwise by the gatekeeper. CDDL licensed changes must + be backed by a Sun Contributor Agreement, so that the changes can + be contributed to the upstream OpenSolaris consolidation. + + Hg commits should have comments of the following form: + + 1234 This is a sample bug report synopsis + 4567 If you have a second bug synopsis... + Reviewed by: codereviewer@somewhere.net + Approved by: gatekeeper@somewhere.else.com + +Branches: + + Please talk to the gatekeeper about personal branches. In general, + they will be allowed as long as we don't go *too* wild on them. + +Gatekeeper: garrett@nexenta.com (Interim) +IRC channel: #illumos on irc.freenode.net +Mailing list: developer@lists.illumos.org +
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/TODO Thu Jul 29 16:07:59 2010 -0700 @@ -0,0 +1,71 @@ + +These are the following bits that were closed source, for which we need +open replacements: + +libc_i18n -- This is probably the most critical part. We should be able to + leverage code from one of the BSDs. + +drivers -- + glm Legacy Symbios/NCR SCSI + ncrs Legacy Symbios/NCR SCSI (EOF? Merge with glm?) + mpt LSI 1068 style SCSI + bcm_sata Broadcom HT-1000 SATA + marvell88sx Marvell SATA + iprb Intel Pro/100 ethernet + ixgb Intel 10GbE (1st gen?) + pcn AMD PC-Net (questionable value) + spwr SMC EPIC/100 (questionable value) + lsimega Mega-RAID + acpi_toshiba Toshiba Tecra M-series ACPI extensions + intel_nhm + intel_nhmex + intel_nb5000 + adpu320 ADP UltraSCSI 320 + bmc IPMI BMC controller -- (OpenIPMI instead?) + bnx Broadcom 1GbE + bnxe Broadcom 10GbE (not sure the difference) + pcser PCMCIA Serial support (questionable value) + se Serial support on legacy SPARC h/w + ce Cassini gigE + ge Sun GEM gigE (derive from eri) + cpqary3 Compaq HBA? + klmmod NFS lock manager + usbser_edge Edgeport USB serial + llc2 LLC2 STREAMS module (not needed?) + Others? + +Platform support: + Various SPARC platform bits + +Crypto: + kcfd -- the crypto framework daemon, implements module signing + ike -- maybe ikev2 (Racoon) + +Commands: + more + sed + tail + patch + printf + pax (Not critical?) + others? + localedef + iconv + snmpd ? + labeld ? + fwflash modules + +Others? + raidcfg plugins? + + +There are other tasks we would like to see done: + + * Support for alternative compilers (gcc, including boot up) + * Self hosting (be able to compile with minimal cross dependencies) + * Increase lint coverage + * Increase 64-bit cleanliness + * Overall Makefile cleanup + +Some of these tasks may conflict with overall goals to minimize differences +with upstream. So that will need to be discussed.