posix1e level of adherence

[Andrew R. Reiter]

Robert,

Awesome, this is what I was looking for exactly.  Thanks.  I did not
realize the posix1e mailing list was still active, but I think there will
be no need to atempt to modify the specification.  

Thanks again,
Andrew

On Tue, 20 Nov 2001, Robert Watson wrote:

:
:On Mon, 19 Nov 2001, Andrew R. Reiter wrote:
:
:> I am currently going through an kind of posix.1e-ifying some of my
:> already done work.. Yet as I go through it I continue to dislike some of
:> what posix1e does and am having a tough time convincing myself to follow
:> it at all times.  We've discussed this before, but since capabilitiies
:> and acl's are ahead of audit, I was wondering if you could briefly let
:> me (and us)  know of the level of commitment you have with the posix1e
:> guide.  Specific information such as whether or not you just comply with
:> the guideline for certain functions, certain data types, and/or other
:> odds and ends would be awesome. 
:
:Sure. :-)
:
:In general, it's nice to follow POSIX.1e, because that encourages
:portability.
:
:Sometimes, the description of a feature provided in POSIX.1e is both
:feasible and useful to implement.  In those cases, we strive for maximum
:compliance, and carefully document any non-portable concerns.  An example
:of this is the ACL spec, where there are few differences between the
:implementation and the spec.
:
:Sometimes, the description of a feature provided in POSIX.1e is useful,
:but because there was limited deployment of the features as specified,
:there are ambiguities or conflicts that must be resolved in
:implementation.  In those situations, it's desirable to maximize
:compliance, where it makes sense, maximizing portability and usefulness
:otherwise.  An example of this is the Capability spec, which is largely
:useful, but some pieces of behavior require clarification from the spec.
:The POSIX.1e mailing list has traditionally been a good place to do this.
:
:Sometimes, the description of a feature provided in POSIX.1e is not
:useful, in which case the logical choice would be to skip out on POSIX1e,
:and possibly consider other types of portability choices.  For example,
:the information labeling and MAC interfaces either describe a feature
:we're currently not interested in (or has limited utility), or describe an
:interface to that feature that is insufficient to support our
:requirements.  In those situations, it is fine to diverge from the
:specification substantially, but it's also a good idea to look at the
:approach taken in other platforms, so that we can adopt ideas from there
:where possible (and maybe even accomplish portability).
:
:I assume, because of your interests, you're refering to the audit spec. 
:You'll notice that I carefully avoided using it as an example: the reason
:for this is that I can't decide what category to put it in, and I've seen
:conflicting views on the topic.  In the two implementations I've worked
:on, I've looked at two different approaches: (1) implement the kernel and
:userland code driven by the description in the specification, and (2) 
:implement the kernel code based on performance and other optimization
:points, and wrap it with userland code to make it look like the spec. 
:Both of those approaches are legitimate.  If you have specific concerns
:about the audit spec, it might be worth raising them on the POSIX.1e
:mailing list. 
:
:Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
:robert at fledge.watson.org      NAI Labs, Safeport Network Services
:
:
:
:

--
Andrew R. Reiter
arr at watson.org
arr at FreeBSD.org


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message