OSDL CGL-WG draft specs available for review

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

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?

Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review

[Mika Kukkonen]

On Tue, 2003-04-22 at 13:55, Christoph Hellwig wrote:
> On Tue, Apr 22, 2003 at 01:46:43PM -0700, Mika Kukkonen wrote:
(...)
> > 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?

Well, there are several ways to convert PDF to ASCII ("pdftotext" in RH9
is one), but as expected they all produce bloody awful results. Better
than nothing, I guess. If you want, I can send the results to you
directly, but I am not going to spam LKML with them (these are reasonable 
long documents).

Thanks for your interest!

--MiKu

Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review

[Christoph Hellwig]

On Tue, Apr 22, 2003 at 02:22:48PM -0700, Mika Kukkonen wrote:
> Well, there are several ways to convert PDF to ASCII ("pdftotext" in RH9
> is one), but as expected they all produce bloody awful results. Better
> than nothing, I guess. If you want, I can send the results to you
> directly, but I am not going to spam LKML with them (these are reasonable 
> long documents).

Yeah, I know - I just hoped you had some way to generate better ASCII
output from the original form of the document..

Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review

[Mika Kukkonen]

On Tue, 2003-04-22 at 14:25, Christoph Hellwig wrote:
> On Tue, Apr 22, 2003 at 02:22:48PM -0700, Mika Kukkonen wrote:
> > Well, there are several ways to convert PDF to ASCII ("pdftotext" in RH9
> > is one), but as expected they all produce bloody awful results. Better
> > than nothing, I guess. If you want, I can send the results to you
> > directly, but I am not going to spam LKML with them (these are reasonable 
> > long documents).
> 
> Yeah, I know - I just hoped you had some way to generate better ASCII
> output from the original form of the document..

OK, we now have a text versions available at SourceForge:
  http://sourceforge.net/docman/index.php?group_id=48444

--MiKu

Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 09:18:45AM -0700, Mika Kukkonen wrote:
> OK, we now have a text versions available at SourceForge:
>   http://sourceforge.net/docman/index.php?group_id=48444

Still look like html to me :)  But anyway lynx-dump gives readable
output, so thanks a lot!

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: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review

[Mika Kukkonen]

On Wed, 2003-04-23 at 09:49, Christoph Hellwig wrote:
> >    4.10 Force unmount (2) 2 Experimental Availability Core
(...)
> This is very hard to get right.  What the expermintel implementation
> you're referring to?

This feature was mentioned in v1.1 spec, so some distributions already
provide "experimental" versions of this feature. There are no Open
Source projects I know of, though.

> >    6.1.1  Real  Time  Support  Performance (1) 1 Experimental Performance
> >    Core
(...)
> Note that without a hard RT extention you'll only get averange latencly,
> but never guaranteed.

Yes, we are aware of this and have accepted this limitation.

> >    6.3.1 Application (Pre)loading Non-root (2) 2 None Performance Core
(...)
> That means it couldn't get paged out, you can't do that without a
> hard limit for user processes.

Well, in the system where the use of app-preloading is planned to done
the unit in question will most likely be diskless, i.e. have no swap.
It will load _all_ of it's applications over network (like NFS) at boot
time (we assume there is enough physical memory). 

Note that this feature requires support in glibc, and I talked with
Ullrich in January and he said he is not going to merge the patch that
was sent to him, because he considers it too off-beat. So this will
require extra work for distros.

> >    6.8 Page flushing 3 Experimental Performance Core
(...)
> 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.

I'll let somebody wiser than me to comment on this one, as I do not
recall the reasoning behind this feature right know ;-)

> >    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.
(...)
> 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 ;-)

One thing that tends to be debated quite often in CGL is that some
people think that POSIX specs are religious texts to be followed
literally, while some believe that the writers were human and so
we should evaluate carefully which POSIX features are actually used by
the industry. Oh well ...

> >    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..

Yes, we follow what is happening around. Really the requirement is just
to get POSIX threads, if it gets done by NPTL we are OK with that. NGPT
is mentioned because some distros currently ship with it and so from
CGL viewpoint fulfill this requirement with NGPT.

> >    8.aem Low-level Asynchronous Events 2 Started Scalability Core
(...)
> 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 :)

Ahem, yes, there has been some ... errr... debate about AEM on
cgl_discussion also. I will just say that asynchronous events seems
to be a required feature, how it gets implemented is different story.

> >    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. 

Well, I'll not get into debate about code quality, but rather I'll point
out that from customers viewpoint:
  a) bad implementation is better than no implementation (well, it is
     easier to "sell" something than nothing ;-)
  b) our spec (and the whole CGL) is only doing "guidance"; what the
     individual projects, distro companies or their customers do is
     out of our hands

As noted in above snippet, we acknowledge that STREAMS (and LiS as project)
probably has no change to get merged, and because of the limited lifetime
of the feature (STREAMS really seems to be a legacy support thingy), it
makes no sense even think about merging STREAMS support to mainline. But
that is our opinion, feel free to disagree.

Thanks for your comments!

--MiKu

Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 11:32:25AM -0700, Mika Kukkonen wrote:
> On Wed, 2003-04-23 at 09:49, Christoph Hellwig wrote:
> > >    4.10 Force unmount (2) 2 Experimental Availability Core
> (...)
> > This is very hard to get right.  What the expermintel implementation
> > you're referring to?
> 
> This feature was mentioned in v1.1 spec, so some distributions already
> provide "experimental" versions of this feature. There are no Open
> Source projects I know of, though.

How do they provide  "experimental" versions of this feature?  I don't
see how this can be done without major fileystem surgery, so it
kindof must be an OSS implementation..

> > 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.

Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available forreview

[Peter Badovinatz]

Mika Kukkonen wrote:
> 
> On Wed, 2003-04-23 at 09:49, Christoph Hellwig wrote:
> > >    4.10 Force unmount (2) 2 Experimental Availability Core
> (...)
> > This is very hard to get right.  What the expermintel implementation
> > you're referring to?
> 
> This feature was mentioned in v1.1 spec, so some distributions already
> provide "experimental" versions of this feature. There are no Open
> Source projects I know of, though.

It is hard to get right, I personally cannot vouch for Solaris 8 or
Veritas (VxFS) having gotten it right.  We list it because of the
expressed desire to control file system mountings in clustered
environments.  One option is to shut down a node where the file system
is mounted, but for various reasons you would like a finer level of
control.

MontaVista claims support (see http://www.mvista.com/tech3.html) in
their Carrier Grade Edition Linux product release.  The 'Experimental'
is because this does exist, but I don't know how well it works, and
whether it's been proposed for mainstream inclusion.

> 
> > >    6.8 Page flushing 3 Experimental Performance Core
> (...)
> > 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.
> 
> I'll let somebody wiser than me to comment on this one, as I do not
> recall the reasoning behind this feature right know ;-)

The goal of this requirement is to allow the applications running on the
system to have deep control of the allocation of system resources.  In
response to some stimulus they can decide they want their allocated
pages released via this hypothetical flush.

A better analogue might be to madvise() and munmap(), although
generalized beyond mmap'ped pages.  In other words, the phrasing needs
to be improved here to be more accurate.  Since most of the text is
mine, and not the folks who've worked with me on it, blame me.

As to implementation, it is 'Experimental' because support exists for
some kinds of pages, ala madvise().  For the more generic case, I see
your point.  In part, we convey this making it priority 3 to allow time
to think on it, but we also don't want to limit possible solutions,
rather identify the need and help inspire the effort.


> > >    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..
> 
> Yes, we follow what is happening around. Really the requirement is just
> to get POSIX threads, if it gets done by NPTL we are OK with that. NGPT
> is mentioned because some distros currently ship with it and so from
> CGL viewpoint fulfill this requirement with NGPT.

Note that NGPT already implemented some specific interfaces [Robust
Mutexes] that are not part of Posix threads (rather, part of Solaris
(Unix International) threads in this case), and this function was
identified as being very important for compatibility for many existing
carrier applications.

I believe that Ulrich has already commented negatively on this support
in glibc/nptl, because it isn't POSIX.  But I'm uncomfortable completely
dropping this from the spec as we're trying to identify requirements as
viewed by some class of users (i.e., carrier applications.)  I can see
an adjustment of priority or other recognition (it's a 1, make it a 2,
and let the discussions play out over time.)

Peter
--
Peter R. Badovinatz aka 'Wombat' -- IBM Linux Technology Center
preferred: tabmowzo@us.ibm.com / alternate: wombat@us.ibm.com
These are my opinions and absolutely not official opinions of IBM, Corp.

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]

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

[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.**