Messages in this thread | | | Subject | Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review | From | Mika Kukkonen <> | Date | 23 Apr 2003 11:32:25 -0700 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |