attributes, architecture, availability, CSI, stability, MT-Level, standard - 接口属性
手册页的属性部分包含一个定义属性类型及其相应值的表。下面提供了属性表的一个示例。并非所有属性类型都适用于所有接口类型。
|
体系结构定义处理器或特定硬件。请参见 uname(1) 的 –p 选项。在某些情况下，体系结构可能表示所需适配器或外围设备。
这表示包含本手册页介绍的命令或组件的软件包。要使用此命令，必须安装指示的软件包。
不依赖于任何代码集的属性的 OS 实用程序和库具有代码集独立性 (Code Set Independence, CSI)。它们具有启用 CSI 的属性。这区别于许多仅使用扩展 Unix 代码集 (Extended Unix Codeset, EUC) 等编码方法的命令和实用程序。扩展 Unix 代码集编码方法允许同时支持最多四个代码集并且通常用于表示亚洲字符集。
不过，出于实际原因，这种独立性不是绝对的。某些假设对当前 CSI 实现依然适用：
文件代码是 ASCII 的超集。
要支持多字节字符和以 null 结尾的 UNIX 文件名，任何多字节字符不能包含 NULL 和 /（斜杠）字符。
仅支持“无状态”文件代码编码。无状态编码可避免移位、锁定移位、指定、调用等，但单一移位未排除在外。
进程代码（wchar_t 值）取决于实现，并且可随时间、实现或语言环境而发生更改。
并非每个对象的名称都可由任意字符组成。下列对象的名称必须由 ASCII 字符组成：
用户名、组名和口令
系统名称
打印机和特殊设备的名称
终端名称 (/dev/tty*)
进程 ID 号
消息队列、信号量和共享内存标签。
下列各项可由 ISO Latin-1 或 EUC 字符组成：
文件名
目录名称
命令名称
Shell 变量和环境变量名称
文件系统挂载点
NIS 键名和域名
NFS 共享文件的名称应由 ASCII 字符组成。尽管文件和目录的名称及内容可由非 ASCII 代码集中的字符组成，但如果仅使用 ASCII 代码集，则允许在任何计算机上挂载 NFS，而不管是否已本地化。对于启用了 CSI 的命令和实用程序，均可以处理 2.6 版本中发布的单字节和多字节语言环境。对于要获取国际化服务完全支持的应用程序，必须应用动态绑定。只有 C 和 POSIX 语言环境才支持静态绑定程序。
Oracle Solaris 通常使开发者提前就能够接触到新技术，这使得开发者能够尽早对这些技术进行评估。遗憾的是，新技术容易发生更改，并且标准化新技术往往会导致接口与以前的版本不兼容。
为了进行合理的风险评估，开发者必须了解接口在将来发行版中发生更改的可能性。为了帮助开发者进行上述评估，某些手册页中提供了命令、入口点和文件格式的接口稳定性信息。
由于 Oracle Solaris 将尽力确保在将来的次要发行版中继续使用这些接口，因此这些接口将更加稳定，可供几乎所有应用程序安全地使用。仅依赖于 "Committed"（已确定）接口的应用程序应在将来的次要发行版中（而不一定在早期发行版中）继续可靠地正常运行。
欠稳定的接口可用于进行实验和设计原型，但使用时必须了解这些接口可能会发生不兼容的更改，甚至可能在将来的次要发行版中被删除或替换为其他接口。
Oracle Solaris 未记录的“接口”（例如，大多数内核数据结构以及系统头文件中的某些符号）可能是实现工件。此类内部接口不仅会发生不兼容的更改或被删除，我们还可能不会在发行说明中提及此类更改。
发行版级别产品具有指定的发行版级别和名称，这些有助于进行兼容性介绍。每个发行版级别还可能包括适合较低级别的更改。
|
例如，与 Oracle Solaris 10 相比，Oracle Solaris 11.0 发行版是主要发行版，因为已从 SVR4 包格式转换到映像包管理系统 (Image Packaging System, IPS)，虽然针对仅调用 Oracle Solaris ABI 中的 "Committed"（已确定）接口的应用程序维护了二进制兼容性。
Oracle Solaris 11.2 是次要发行版，尽管添加了重大功能（例如，内核区域和统一归档），但与 Oracle Solaris 11.0 或 11.1 发行版相比，并没有此类不兼容的更改。
Oracle Solaris 附带的软件的发行版级别可能并不总是反映 Oracle Solaris 本身的发行版级别。例如，Oracle Solaris 的宏发行版（例如，Support Repository Update）可能包含捆绑的软件包的主要发行版，例如，Oracle Java 运行时环境或 FOSS 语言解释程序。
分类下表概述了稳定性级别分类与发行版级别的关系。第一列中列出了稳定性级别。第二列中列出了不兼容的更改所对应的发行版级别，第三列中列出了其他注释。有关各分类的完整讨论，请参见下文的相应小节。
|
除非另有说明，否则本手册页中介绍的接口稳定性级别分类适用于源代码接口和二进制接口。所有稳定性级别分类都是公共的，但 "Private"（专用）分类除外。除非明确说明，否则不会指定公共接口（即本手册页中记录的接口）的确切稳定性级别。未记录接口的稳定性级别缺省为 "Private"（专用）。
除了 Oracle Solaris 产品中包含的文档以外，其他现有文档不应解释为暗指 Oracle Solaris 产品所提供接口的任何稳定性级别。参考手册页是稳定性级别信息的唯一来源。
Committed（已确定）接口的用途在于使第三方能够针对这些接口开发和发布应用程序，并确信这些应用程序能够在引入接口的产品发行版的所有后续发行版（属于同一主要发行版）中正常运行。即使在主要发行版中，不兼容的更改也应当极少出现，并且应具有正当理由。
作为行业标准定义和控制的接口通常视为 Committed（已确定）接口。在这种情况下，属性表中的“标准”条目或其他文档位置通常会说明监管机构和/或公共文档版本。
虽然不兼容的更改很少发生，但是如果相关缺陷极其严重（如本文档的“例外情况”部分中所述），在任何发行版中都可能会发生不兼容的更改；或者在次要发行版中，可能会通过“功能终止”过程来进行不兼容的更改。如果必须停止对 Committed（已确定）接口的支持，Oracle Solaris 将会尝试提供通知并将稳定性级别标记为 "Obsolete"（已过时）。
不对这些接口在不同次要发行版中的源代码或二进制兼容性进行任何承诺。甚至在次要发行版中可能会发生接口删除等重大的不兼容更改。Uncommitted（未确定）接口通常不适用于与发行版无关的产品。
对接口进行不兼容更改旨在对接口进行实质性的改进（包括考虑到易用性等因素）。一般情况下，Uncommitted（未确定）接口不太可能进行不兼容的更改，如果发生此类更改，这些更改将影响甚微，并且通常具有减轻风险计划。
Uncommitted（未确定）接口通常属于下列子类别之一：
实验性或过渡性接口。这些接口通常旨在使外部开发者可以及早接触到一些新兴的、不断发展变化的技术，或者提供一个临时的解决问题的办法，有待将来再寻求更通用的解决方案。
其规范由外部机构控制的接口，但 Oracle Solaris 希望在提供与外部规范同步的下一个次要发行版之前尽力与以前的发行版保持兼容。
相较于稳定性而言，其目标用户更重视创新（或者易用性）的接口。此属性通常与较高层组件的管理接口相关联。
对于 Uncommitted（未确定）接口，Oracle Solaris 不会对不同次要发行版之间的源代码或二进制兼容性做出任何声明。根据这些接口开发的应用程序可能无法在将来的次要发行版中运行。
Volatile（可变）接口可能出于任何原因而随时发生更改。
通过 Volatile（可变）接口稳定性级别，Oracle Solaris 产品可以快速跟上不断发展变化的规范。在许多情况下，与为接口提供额外的稳定性相比，"Volatile"（可变）接口能够更好地满足使用者的期望，因此人们更喜欢使用 "Volatile"（可变）接口。
此分类级别最常应用于由 Oracle Solaris 以外的机构控制的接口，但与重视接口兼容性的标准机构或免费/开源软件 (Free or Open Source Software, FOSS) 社区控制的规范不同的是，无法声明极少对接口规范进行的不兼容更改。此外，此接口还适用于由 FOSS 控制的软件，对于此类软件，大家认为在最短时间内了解社区动态比向我们的客户提供稳定性更为重要。
通常还可以在可靠组织或广泛认可的组织定义接口的过程中，将 Volatile（可变）分类级别应用于接口。这些级别通常称为标准草案。“IETF Internet 草案”就是一个广为人知的正在开发的规范的示例。
此外，实验性接口也可以是 Volatile（可变）接口。
我们不对任何两个发行版（包括修补程序）之间的 Volatile（可变）接口的源代码或二进制兼容性做出任何声明。包含这些接口的应用程序可能无法在将来的任何发行版中正常运行。
有时会出现以下情况：推断存在的某个实体可能是一个接口，但实际上却并非是接口。常见示例包括：仅供人员使用的 CLI 的输出以及 GUI 的确切布局。
此分类是一个适合用于阐明确定可能存在此类混淆的术语。如果无法对实体应用此术语，也并不意味着该实体就是某种形式的接口。它仅表明未确定可能存在此类混淆。
Private（专用）接口是由组件（或产品）提供的专用于该组件的接口。Private（专用）接口仍对其他组件可见或可由其他组件访问。由于使用其他组件的专用接口存在巨大的稳定性风险，因此明确不支持这种使用方式。不是由 Oracle Solaris 提供的组件不应使用 Private（专用）接口。
大多数 Private（专用）接口都未予以记录。我们很少记录 Private（专用）接口。记录 Private（专用）接口的原因包括（但不限于）：该接口用途可能会在将来重新分类为某个公共稳定性级别分类，或者该接口会无规律地显现。
"Obsolete"（已过时）是可与上述分类级别一起显示的修饰符。"Obsolete"（已过时）修饰符表示接口“已弃用”并且/或者建议不要继续用于一般用途。通过应用 "Obsolete"（已过时）修饰符，现有接口可从某个其他状态（例如，"Committed"（已确定）或 "Uncommitted"（未确定））发生降级，以便建议客户先从该接口进行迁移，然后再删除（或以不兼容方式更改）该接口。
当前发行版支持 "Obsolete"（已过时）接口，但计划在将来的（次要）发行版中将其删除。停止接口支持之前，Oracle Solaris 将会首先尝试提供通知，然后再停止支持相应接口。使用 "Obsolete"（已过时）接口会生成警告消息。
Pass-through（让渡）是可与上述分类级别一起显示的修饰符。Pass-through（让渡）修饰符指示这样的接口：其规范由 Oracle Solaris 以外的任何机构（通常为免费/开源软件团体）监管，且已通过微小修改（通常只是使组件在 Oracle Solaris 上正常运行所需的修改）进行“让渡”。
根据监管每个 Pass-through（让渡）接口的外部机构在稳定性（低，更改慢）和灵活性（高，更改快）方面的进展，在与发行版无关的产品中使用此类接口的风险会有所变化。Oracle 不承诺使这些接口的任何使用者避免遇到这些外部机构引入的不兼容情况。尤其是，当外部机构不再支持其组件的某个给定版本时，Oracle Solaris 通常会效仿并在之后不久不再支持该版本（通常会支持更高版本）。请注意，“不再支持”可能意味着删除，即使是在微发行版中。有关如何冻结某个组件以允许以不支持的方式继续使用的信息，请参见 pkg(1) 手册页。
在极少情况下，为了维护 Oracle Solaris 和客户的最佳利益，需要违反接口稳定性承诺。下表包含接口提供者违反接口稳定性确定的常见已知原因，但不排除存在其他原因。
存在安全漏洞（接口固有的漏洞）。
发生数据损坏（接口固有的漏洞）。
违反标准的情况（由一致性测试的解释或改进中的更改所揭示）。
某个非由 Oracle Solaris 控制的接口规范已发生不兼容的更改，并且大多数接口使用者都希望提供更新的接口。
对于客户来说，不进行不兼容更改是无法接受的。例如，在放弃 DOS 8.3 命名限制后，如果不对 pcfs 进行不兼容的更改，就会是一个这样的示例。
外部机构不再支持某个 Pass-through（让渡）组件的特殊版本。例如，Python 团体不再支持版本 2.6，而是支持版本 2.7 和 3.x）。
例外情况允许的不兼容更改将始终尽可能在“最主要的”发行版中提供。但是，漏洞带来的后果或合同相关规定要求往往会强制在修补程序中提供。
与早期接口分类机制的兼容性在 Solaris 10 以及先前的发行版中，采用不同的接口分类机制。下表概述了新旧分类机制之间的映射。
|
免费/开源软件的重要性日益提高，促使将名称从 "Stable"（稳定）/"Unstable"（不稳定）更改为 "Committed"（已确定）/"Uncommitted"（未确定）。"Stable"（稳定）一词与该术语在 FOSS 社区中的常见用途相冲突。
"Evolving"（发展中）的定义比较模糊，导致很难理解此术语。在迁移到新分类机制的过程中，以前的许多 "Evolving"（发展中）的接口都已升级为 "Committed"（已确定）。不过，在遇到术语 "Evolving"（发展中）时，应推断为 "Uncommitted"（未确定）。
库分为若干类别，这些类别定义了其支持多个线程的能力。包含属于多个或不同级别的函数的手册页在“附注”部分或“用法”部分中对此方面进行了介绍。
“安全”是可从多线程应用程序调用的代码的属性。调入安全接口或安全代码段的作用是：即使由多个线程调用，结果仍然有效。人们常常忽视的一点是：此安全接口或安全代码段的结果可产生影响所有线程的全局后果。例如，从一个线程打开或关闭文件的操作对进程中的所有线程都可见。多线程应用程序负责安全地使用这些接口，这与此接口是否安全有所不同。例如，关闭应用程序中其他线程仍在使用的文件的多线程应用程序未安全地使用 close(2) 接口。
非安全库包含不受保护的全局和静态数据。除非应用程序安排每次仅在库中执行一个线程，否则使用此库会不安全。非安全库可能包含安全函数；不过，库包含的大多数函数在调用时都是不安全的。某些非安全函数具有多线程安全的可重入函数。可重入函数由附加到函数名称的 _r 后缀指定。
多线程安全库是为多线程访问而充分准备的库。它通过锁定保护其全局和静态数据，并且可提供合理数目的并发性。可以安全使用的库并不能视为多线程安全。例如，使用监视器监视整个库可使库保持安全，但它不支持并发性，因此不能视为多线程安全。多线程安全库必须允许合理数目的并发性。（此定义的目的是精确定义安全库的含义。安全库的定义不会指定该库是否支持并发性。多线程安全定义明确指明该库是安全的，并且支持一定程度的并发性。这阐明了安全定义，它可以表示从单线程到任何并发度的多线程的所有内容。）
“异步信号安全”表示可从信号处理程序安全地调用的特定库函数。执行异步信号安全函数的线程在被信号中断时，自身不会发生死锁。信号只会为获取锁定的多线程安全函数带来问题。
异步信号安全函数也具有多线程安全性。在异步信号安全函数中获取锁定时，将禁用信号。这些信号用于防止调用可能获取相同锁定的信号处理程序。
有关异常的说明，请参见这些页面的“附注”部分或“用法”部分。
有关异常的说明，请参见这些页面的“附注”部分或“用法”部分。
fork(2) 函数仅在子进程中复制调用线程。fork1(2) 函数的存在目的是为了与以前版本兼容，它与 fork() 同义。当调用 fork() 时，如果未在执行派生的其他线程保持锁定，该锁定仍将保持在子进程中，但是由于未复制所属线程，因此没有锁定所有者。调用尝试获取锁定的函数的子进程自身将发生死锁。
当调用 fork() 时，Fork 安全库安排仅让执行派生的线程保留该库的所有内部锁定。这通常是使用 pthread_atfork(3C) 实现的，该函数在初始化库时调用。
在极少情况下，如果进程需要在执行派生时复制其所有线程，forkall(2) 函数会提供此功能。调用 forkall() 时，不会执行 pthread_atfork() 操作。调用 forkall() 存在相应的危险。当某个线程调用 forkall() 时，如果进程中的某些其他线程正在执行 I/O 操作，这些线程将继续在父进程和子进程中执行相同的 I/O 操作，这可能会导致数据损坏。出于此原因以及其他竞争情况原因，不建议使用 forkall()。
在 Solaris 10 之前的所有 Solaris 发行版中，fork() 的行为取决于应用程序是否与 –lpthread 相链接（有关 POSIX 线程，请参见 standards(7)）。如果与 –lpthread 链接，fork() 的行为与 fork1() 相似，否则与 forkall() 相似。为了避免产生有关 fork() 行为的任何混淆，应用程序可以根据需要明确地调用 fork1() 或 forkall()。
如果多线程应用程序使用 pthread_cancel(3C) 取消（即中止）线程，目标线程在中止时可能会保留某项资源，例如锁定或分配的内存。如果线程未安装有适当的取消清除处理程序来释放相应资源（请参见 pthread_cancel(3C)），该应用程序即为“取消不安全”，也就是说，从线程取消方面来说，该应用程序不安全。由于取消的线程未释放锁定，这种非安全性可能导致死锁或资源泄漏；例如，不会在取消线程时释放内存。使用 pthread_cancel(3C) 的所有应用程序都应确保它们在“取消安全”环境中运行。此外，如果库具有取消点并且获取锁定等资源或动态分配内存，也会导致与这些库关联的应用程序的取消不安全性。这为多线程程序中的库引入了另一个安全级别：取消安全。取消安全包含两个子类别：延迟取消安全以及异步取消安全。如果应用程序对于取消类型为 PTHREAD_CANCEL_DEFERRED 的线程为取消安全时，该应用程序被视为延迟取消安全。如果应用程序对于取消类型为 PTHREAD_CANCEL_ASYNCHRONOUS 的线程为取消安全时，该应用程序被视为异步取消安全。由于具有延迟取消类型的线程只能在正确定义的取消点取消，而具有异步取消类型的线程可在任意位置取消，因此延迟取消安全比异步取消安全更容易实现。缺省情况下，创建的所有线程都具有延迟取消类型，因此可能永远不需要担心异步取消安全。大多数应用程序和库都应当始终为异步取消不安全。根据定义，异步取消安全的应用程序同时也是延迟取消安全的。
许多接口都作为行业标准进行定义和控制。在这种情况下，本部分中将说明监管机构和/或公共文档版本。
程序员在生成可移植应用程序时，应该遵照此应用程序应符合的标准或规范中提供的接口说明，而不能遵照基于公共标准的接口的手册页说明。当标准或规范允许采用替代实现选择时，手册页通常仅介绍由 Oracle Solaris 实现的替代项。手册页还介绍对 Oracle Solaris 提供的标准接口的基本定义的所有可兼容扩展。
对于文中引用的监管机构或文档，并不意味着我们将其认可为“标准”条目。监管机构可以是非常正式的组织（例如 ISO 或 ANSI）、较不正式但广泛接受的组织（例如 IETF）或非正式的独立贡献者（例如 FOSS（Free or Open Source Software，免费/开源软件）贡献者）。
uname(1)、intro(3)、 standards(7)
功能终止声明 (http://www.oracle.com/technetwork/systems/end-of-notices/)