X (was: New version of capabilities patch online, some more status)

[Jeffrey W. Thompson]

I had meant to respond to the issue of T6 being a requirement earlier, but forgot
to include that in my email.

T6 is in fact (or something that provides similar functionality) is only a
requirement if you are going to be working in an environment where multiple B1 OS's
are going to be transferring labels over the network to eachother and need those
labels to interoperate.  In this case if you wanted an X server on TrustedBSD to
communicate with a TrustedLinux implementation that has an entirely different label
API then you would need a full T6 implementation.

If your concern is simply the transferrence of network labels (without
interroperability concerns) then you can solve this problem with a limited SAMP
implementation that does not use a token mapping service.  This is considerably
easier than a full T6 implementation.  Further more, from X's perspective you
really only need a mechanism that allows you to read and write labels on socket
based connections.  Under PitBull this is done with a ebind, eread, ewrite
interface and under Trusted Solaris (if memory serves me correctly) readl, writel.

A way to get things up and running quickly would be to implement the t6 libraries
and only have them use the eread/ewrite (or equivalent TrustedBSD versions).  This
would allow people working on X to develop to the T6 API without having to have a
full T6 implementation.  When and if a full T6 implementation is done, the T6
libraries could be updated and the transition would be fairly painless.

I certainly recognize the value of a full t6 implementation (though there is a
performance impact) but in my experience it isn't really necessary in many cases.
Again, I am talking mainly about server based architectures, and it could become
relevant again in a more client-centric architecture, but I suspect it is not
necessary to make it an immediate priority.

As long as noone suggests implementing DNSIX I'll be happy!

Jeff


richard offer wrote:

> * $ from thompson at argus-systems.com at "1-May: 3:03pm" | sed "1,$s/^/* /"
> *
> *
> *
> * One issue to rolling the modifications into the main tree is going to be the
> * various differences between Trusted Operating Systems.  We will all likely
> want to
> * get the tree running on our platforms.
>
> If the first platform to have a useable T6 is BSD I'm quite willing to use that
> to get X working.
>
> * There are going to be at least three
> * mainstream API variants in the near future (Argus PitBull on Solaris, AIX,
> Linux,
> * and UnixWare), TrustedBSD (on FreeBSD), and the forthcoming (this is
> correct?) SGI
> * port (on Linux).  While it seems unlikely that we will all agree on a mutual
> API,
> * it is probably in all of our interests to have a good discussion on
> portability
> * issues between APIs for application level development.
>
> In an ideal world, I'd like to see one userland set of APIs, two I could live
> with, three and we're now getting into problems.
>
> Being a user-level person, I don't really care that the kernels are all
> different, I care that I have to port my application code to three different
> APIs. For those APIs that are common (say regular expressions) thats bad
> enough, but for un-common APIs (this work) that's only going to lead to
> problems, with lack of coverage and a smaller user base. And presumably we're
> all going to be contributing our patches back to the authors...As an author,
> the last thing I'd want to do is modify my code three times for the same niche
> market with no way to test interopability.
>
> Historicaly, we've all had existing baggage to carry along with us, now we have
> the option of working out these differences to make all our lives easier.
>
> I'm not wedded to the SGI APIs, we put the sample code out to generate
> interest, not as a force-feeding of an API. We'd obviously like something close
> to it (and draft POSIX) as possible, but that doesn't mean I'm going to take my
> ball and go and play elsewhere.
>
> If we could get one common API between Linux and BSD, I'd prefer that, instead
> of insisting on rolling our own because of a case of NIH.
>
> As an example, if we do go with different APIs we'd better work out a plan for
> autoconf/imake configuration to at least provide some sort of compile plan for
> third party apps.
>
> *
> * Cheers,
> *
> * Jeff
> *
>
> richard.
>
> -----------------------------------------------------------------------
> Richard Offer           Widget FAQ --> http://reality.sgi.com/widgetFAQ
> MTS-Core Design (Motif)
> ___________________________________________http://reality.sgi.com/offer
>
> To Unsubscribe: send mail to majordomo at trustedbsd.org
> with "unsubscribe trustedbsd-discuss" in the body of the message

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