Re: OSDL CGL-WG draft specs available for review

Re: OSDL CGL-WG draft specs available for review

[Fleischer, Julie N]

On Wed, Apr 23, 2003 at 1:22 PM, Christoph Hellwig wrote:
> On Wed, Apr 23, 2003 at 11:32:25AM -0700, Mika Kukkonen wrote:
> > On Wed, 2003-04-23 at 09:49, Christoph Hellwig wrote:
> > > Without really big kernel changes it's hard to get full 
> POSIX thread
> > > semantics. e.g. we still don't have credential sharing 
> for tasks.  And
> > > it doesn't lool like this makes 2.6.  I'd rather remove this one..
> > 
> > Ah, we are not aiming to get our features into a certain 
> kernel version,
> > and actually we do not expect or even want (because of 2.6
> > stabilization) that our v2 spec kernel features get merged 
> into 2.6 at
> > this point of time (some of them might, though).
> > 
> > For us it is enough that the distros will pick most of the features
> > after v2 specs get released and through that adaption some of
> > those features will get merged into 2.7 or whatever is 
> coming after 2.6.
> > So we are not in hurry ;-)
> 
> Well, this is not doable ontop of any existing kernel without major
> suregery (introducing a credential cache and passing it down to
> every place that's doing uid/gid based access control).
> 
> So none of the CGL distros can really support that.

>From the POSIX Test Suite perspective, we were planning on first focusing
testing on the CGL 2.0 priority 1 POSIX features, which would mean the
threads functions with the THR tag in IEEE1003.1-2001.  But, it would be
great to know what gaps current implementations (like NPTL) have against
this tag in the POSIX spec.  Is there a way we can get more details on the
current gaps you mentioned?  I'm wondering how they will affect conformance
to the THR tag functions.

- Julie Fleischer

**These views are not necessarily those of my employer.**

Re: OSDL CGL-WG draft specs available for review

[Christoph Hellwig]

On Thu, Apr 24, 2003 at 11:39:29AM +0200, Carl-Daniel Hailfinger wrote:
> IIRC, Mark Huth from MontaVista and Tigran Aivazian from Veritas both
> developed such an implementation independently of each other.
> Maybe they can offer some insight.

Tigran had a revoke(2) implementation - that's forced revokation of
a fd, not forced umount.  But maybe he did forced umount, too? :)

Re: OSDL CGL-WG draft specs available for review

[Carl-Daniel Hailfinger]

[CC:ed Mark Huth and Tigran Aivazian]

Christoph Hellwig wrote:
>    4.10 Force unmount (2) 2 Experimental Availability Core
>    4.10 Description: 
> 
>    CGL shall support forced unmounting of a filesystem.
>      * The  unmount should work even if there are open files or processes
>        in the file system.
>      * Pending  requests  should  be  ended with an error return when the
>        file system is unmounted.
> 
> 
> This is very hard to get right.  What the expermintel implementation
> you're referring to?

IIRC, Mark Huth from MontaVista and Tigran Aivazian from Veritas both
developed such an implementation independently of each other.
Maybe they can offer some insight.

Regards,
Carl-Daniel

Re: OSDL CGL-WG draft specs available for review

[Christoph Hellwig]

>    4.10 Force unmount (2) 2 Experimental Availability Core
>    4.10 Description: 
> 
>    CGL shall support forced unmounting of a filesystem.
>      * The  unmount should work even if there are open files or processes
>        in the file system.
>      * Pending  requests  should  be  ended with an error return when the
>        file system is unmounted.

This is very hard to get right.  What the expermintel implementation
you're referring to?

>    Reference projects:
>    6.1.1  Real  Time  Support  Performance (1) 1 Experimental Performance
>    Core
>    6.1.1 Description: 
> 
>    CGL  shall  provide  the  capability  of  configuring the scheduler to
>    provide  soft  real  time  support  so  that  the real time scheduling
>    latency  of  a  given  task  will  not  exceed a target offered by the
>    vendor.
>      * This  requirement  requires  that  a latency target can be set and
>        depended  upon.  As an approximation, on common commodity hardware
>        supported  by  Linux,  latency  responses in the range of 10 to 15
>        milliseconds should be considered reasonable and likely.
>      * The Validation suite can likewise specify a methodology to allow a
>        vendor  to  specify  a latency value and provide verification that
>        the specified value is satisfied.

Note that without a hard RT extention you'll only get averange latencly,
but never guaranteed.

>    6.3.1 Application (Pre)loading Non-root (2) 2 None Performance Core
>    6.3.1 Description: 
> 
>    Applications  need  to  be able to exploit the application pre-loading
>    capability  even  when they are not executing as root. A configuration
>    capability  needs  to  exist  to  allow the system loader to determine
>    eligible applications for being pre-loaded.

That means it couldn't get paged out, you can't do that without a
hard limit for user processes.

>    6.8 Page flushing 3 Experimental Performance Core
>    6.8 Description: 
> 
>    CGL  shall  allow  either  applications  or  the operator controllable
>    parameters  to  control  page-flushing  operations  to  control system
>    impact.
>      * This  capability  should  be  configurable  on  a  per-process  or
>        per-application basis and also as a global setting.
>      * The  Proof  of Concept and Architecture subgroups need to consider
>        what forms an API to support this should take.
>      * Security  needs  to  be  addressed  as  mis-  or  over-use of this
>        capability can have severe impacts on the system.
> 
>    Existing functions such as fsync() and fdatasync() are starting points
>    to describe this. The difference here is that these apply to files and
>    need  to  be  executed  by  the  application  itself rather than by an
>    administrator  or  a  "manager  program"  that monitors the system and
>    adjusts  for  different requirements. For this requirement, the system
>    needs  to also be able to flush an applications memory pages onto swap
>    space.

I don't see how you want to implement this.  The fundamental VM object
for page flushing is struct address_space and it's in no say related to
processes.

>    OSDL CGL shall provide POSIX-compatible interfaces to support direct
>    porting of common carrier grade applications. OSDL CGL shall follow
>    the IEEE Std 1003.1-2001 POSIX standard for the functional areas
>    listed below.
> 
>    The IEEE Std 1003.1-2001 POSIX System Interfaces, Issue 6 delineates
>    functional areas using margin codes. This requirements document
>    identifies those margin codes which are required or optional for a
>    POSIX distribution. The POSIX functionality required by OSDL CGL is:
>     1. Core POSIX functionality
>     2. POSIX Timers functionality
>     3. POSIX Signals functionality
>     4. POSIX Threads functionality

Without really big kernel changes it's hard to get full POSIX thread
semantics. e.g. we still don't have credential sharing for tasks.  And
it doesn't lool like this makes 2.6.  I'd rather remove this one..

>    Reference projects:
>      * Implemented in NGPT: [94]http://www-124.ibm.com/pthreads/.

Well, NGPT is maintaince only mode and I doubt there's much chance to see
this ever in glibc/ngpt.  I'd rather check this with Ullrich before adding
it to the spec..

>    8.aem Low-level Asynchronous Events 2 Started Scalability Core
>    8.aem Description: 
> 
>    OSDL  CGL  WG  specifies  that Carrier-Grade Linux 2.0 shall provide a
>    very  efficient  capability for handling a large number of essentially
>    simultaneous  asynchronous events arriving on multiple channels (e.g.,
>    multiple sockets or other similar paths.)
> 
>    CGL  needs  to  have  an  efficient  mechanism that provides the Linux
>    kernel  with  advanced  carrier-grade  capabilities. The motivation of
>    this mechanism is to enforce the system scalability and soft real-time
>    responsiveness  by  reducing contentions appearing at the kernel level
>    especially under high load.
>    8.aem POC Referrals: 
> 
>    Reference projects:
>      * Ericsson       AEM       (Asynchronous      Event      Mechanism):
>        http://sourceforge.net/projects/aem/

AEM seems like a very bad idea to add to any spec.  The code is a mess and
does about three different things that don't belong together.  Better
don't even mention it :)

>    Keeping  it  separate from the base kernel (i.e. using LIS) also would
>    be  the prudent thing to do, as providing streams in the kernel got an
>    unfavorable reception in the past in the LKML.

Code doesn't get any better by keeping it outside the tree.  This only means
issues don't get fixed - LiS is the best example for this. 

Re: OSDL CGL-WG draft specs available for review

[Christoph Hellwig]

On Tue, Apr 22, 2003 at 01:46:43PM -0700, Mika Kukkonen wrote:
> Hello!
> 
> Influenced by the feedback we got around the release of our version 1 specs,
> OSDL CGL Work Group has made the decision to follow a more open process
> with the next version of our specifications.
>  
> Accordingly, we have made the initial drafts of the first two parts of
> our version 2 specifications available at:
> 	http://www.osdl.org/projects/cgl/
> for public review and comment.

What about an ASCII version so quoting is possible?

OSDL CGL-WG draft specs available for review

[Mika Kukkonen]

Hello!

Influenced by the feedback we got around the release of our version 1 specs,
OSDL CGL Work Group has made the decision to follow a more open process
with the next version of our specifications.
 
Accordingly, we have made the initial drafts of the first two parts of
our version 2 specifications available at:
	http://www.osdl.org/projects/cgl/
for public review and comment.
 
These two parts address the "General OS requirements" and "Security".
There is also a third part called "Clustering", that has been delayed,
but should hopefully made available by the end of this month.

We invite everybody to download the specs and comment. We have an open
mail list, cgl_discussion@osdl.org, for detailed discussion and comment.
You can also mail the feedback directly to me (mika@osdl.org), if you
so prefer, and of course we will read the LKML also. Your choice.

Please keep in mind that these are early drafts and so in now way reflect
the final content of the final version which is scheduled to be ready around
July. So now is your best chance to influence this document!

Cheers!

On the behalf of OSDL CGL-WG,
   Mika Kukkonen
   CGL Roadmap Coordinator
   mika@osdl.org