[lkml]   [2003]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [cgl_discussion] Re: OSDL CGL-WG draft specs available for review
    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]
    > 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!


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:34    [W:0.027 / U:32.100 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site