* OSDL CGL-WG draft specs available for review @ 2003-04-22 20:46 Mika Kukkonen 2003-04-22 20:55 ` Christoph Hellwig 2003-04-23 16:49 ` Christoph Hellwig 0 siblings, 2 replies; 12+ messages in thread From: Mika Kukkonen @ 2003-04-22 20:46 UTC (permalink / raw) To: LKML; +Cc: cgl_discussion 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OSDL CGL-WG draft specs available for review 2003-04-22 20:46 OSDL CGL-WG draft specs available for review Mika Kukkonen @ 2003-04-22 20:55 ` Christoph Hellwig 2003-04-22 21:22 ` [cgl_discussion] " Mika Kukkonen 2003-04-23 16:49 ` Christoph Hellwig 1 sibling, 1 reply; 12+ messages in thread From: Christoph Hellwig @ 2003-04-22 20:55 UTC (permalink / raw) To: Mika Kukkonen; +Cc: LKML, cgl_discussion 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review 2003-04-22 20:55 ` Christoph Hellwig @ 2003-04-22 21:22 ` Mika Kukkonen 2003-04-22 21:25 ` Christoph Hellwig 0 siblings, 1 reply; 12+ messages in thread From: Mika Kukkonen @ 2003-04-22 21:22 UTC (permalink / raw) To: Christoph Hellwig; +Cc: LKML, cgl_discussion 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review 2003-04-22 21:22 ` [cgl_discussion] " Mika Kukkonen @ 2003-04-22 21:25 ` Christoph Hellwig 2003-04-23 16:18 ` Mika Kukkonen 0 siblings, 1 reply; 12+ messages in thread From: Christoph Hellwig @ 2003-04-22 21:25 UTC (permalink / raw) To: Mika Kukkonen; +Cc: LKML, cgl_discussion 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.. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review 2003-04-22 21:25 ` Christoph Hellwig @ 2003-04-23 16:18 ` Mika Kukkonen 2003-04-23 16:26 ` Christoph Hellwig 0 siblings, 1 reply; 12+ messages in thread From: Mika Kukkonen @ 2003-04-23 16:18 UTC (permalink / raw) To: Christoph Hellwig; +Cc: LKML, cgl_discussion 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review 2003-04-23 16:18 ` Mika Kukkonen @ 2003-04-23 16:26 ` Christoph Hellwig 0 siblings, 0 replies; 12+ messages in thread From: Christoph Hellwig @ 2003-04-23 16:26 UTC (permalink / raw) To: Mika Kukkonen; +Cc: LKML, cgl_discussion 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! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OSDL CGL-WG draft specs available for review 2003-04-22 20:46 OSDL CGL-WG draft specs available for review Mika Kukkonen 2003-04-22 20:55 ` Christoph Hellwig @ 2003-04-23 16:49 ` Christoph Hellwig 2003-04-23 18:32 ` [cgl_discussion] " Mika Kukkonen 2003-04-24 9:39 ` OSDL CGL-WG draft specs available for review Carl-Daniel Hailfinger 1 sibling, 2 replies; 12+ messages in thread From: Christoph Hellwig @ 2003-04-23 16:49 UTC (permalink / raw) To: Mika Kukkonen; +Cc: LKML, cgl_discussion > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review 2003-04-23 16:49 ` Christoph Hellwig @ 2003-04-23 18:32 ` Mika Kukkonen 2003-04-23 20:22 ` Christoph Hellwig 2003-04-23 22:03 ` [cgl_discussion] Re: OSDL CGL-WG draft specs available forreview Peter Badovinatz 2003-04-24 9:39 ` OSDL CGL-WG draft specs available for review Carl-Daniel Hailfinger 1 sibling, 2 replies; 12+ messages in thread From: Mika Kukkonen @ 2003-04-23 18:32 UTC (permalink / raw) To: Christoph Hellwig; +Cc: LKML, cgl_discussion 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review 2003-04-23 18:32 ` [cgl_discussion] " Mika Kukkonen @ 2003-04-23 20:22 ` Christoph Hellwig 2003-04-23 22:03 ` [cgl_discussion] Re: OSDL CGL-WG draft specs available forreview Peter Badovinatz 1 sibling, 0 replies; 12+ messages in thread From: Christoph Hellwig @ 2003-04-23 20:22 UTC (permalink / raw) To: Mika Kukkonen; +Cc: LKML, cgl_discussion 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available forreview 2003-04-23 18:32 ` [cgl_discussion] " Mika Kukkonen 2003-04-23 20:22 ` Christoph Hellwig @ 2003-04-23 22:03 ` Peter Badovinatz 1 sibling, 0 replies; 12+ messages in thread From: Peter Badovinatz @ 2003-04-23 22:03 UTC (permalink / raw) To: Mika Kukkonen; +Cc: Christoph Hellwig, LKML, cgl_discussion 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OSDL CGL-WG draft specs available for review 2003-04-23 16:49 ` Christoph Hellwig 2003-04-23 18:32 ` [cgl_discussion] " Mika Kukkonen @ 2003-04-24 9:39 ` Carl-Daniel Hailfinger 2003-04-24 9:46 ` Christoph Hellwig 1 sibling, 1 reply; 12+ messages in thread From: Carl-Daniel Hailfinger @ 2003-04-24 9:39 UTC (permalink / raw) To: Christoph Hellwig Cc: Mika Kukkonen, LKML, cgl_discussion, Mark Huth, Tigran Aivazian [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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OSDL CGL-WG draft specs available for review 2003-04-24 9:39 ` OSDL CGL-WG draft specs available for review Carl-Daniel Hailfinger @ 2003-04-24 9:46 ` Christoph Hellwig 0 siblings, 0 replies; 12+ messages in thread From: Christoph Hellwig @ 2003-04-24 9:46 UTC (permalink / raw) To: Carl-Daniel Hailfinger Cc: Christoph Hellwig, Mika Kukkonen, LKML, cgl_discussion, Mark Huth, Tigran Aivazian 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? :) ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-04-24 9:34 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-04-22 20:46 OSDL CGL-WG draft specs available for review Mika Kukkonen 2003-04-22 20:55 ` Christoph Hellwig 2003-04-22 21:22 ` [cgl_discussion] " Mika Kukkonen 2003-04-22 21:25 ` Christoph Hellwig 2003-04-23 16:18 ` Mika Kukkonen 2003-04-23 16:26 ` Christoph Hellwig 2003-04-23 16:49 ` Christoph Hellwig 2003-04-23 18:32 ` [cgl_discussion] " Mika Kukkonen 2003-04-23 20:22 ` Christoph Hellwig 2003-04-23 22:03 ` [cgl_discussion] Re: OSDL CGL-WG draft specs available forreview Peter Badovinatz 2003-04-24 9:39 ` OSDL CGL-WG draft specs available for review Carl-Daniel Hailfinger 2003-04-24 9:46 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).