[lsb-discuss] New Interfaces for 3.2/4.0
nick at usenix.org
Wed Aug 2 09:33:33 PDT 2006
On Wed, 2006-08-02 at 09:20 -0700, Wichmann, Mats D wrote:
> >>>From the LSB perspective, the behavior required by
> >> these has long been required (interfaces like mmap,
> >> mlockall, and mlock).
> >> For embedded-type systems it may not make sense (I presume
> >> the mmu-less systems fall in this general category), but
> >> that's covered, I believe, by the quote
> >> "This does not include systems using subprofiles"
> >Let's make sure we don't do anything that precludes or greatly
> >complicates an LSB Embedded. We frequently get questions about
> >if and when we're going to do one of those, and our standard
> >answer is that we'd be happy to serve as a vehicle for
> >such an effort if the right companies were interested in getting
> >involved. As it stands now, we have neither the
> >resources nor the expertise, which is why we haven't pursued it.
> Right. The context I was trying to put this in was these
> are options for POSIX; the thought is making them non-optional
> (but smaller systems could still use the subprofiles
> mechanism to exclude them). For LSB-core, the interfaces in
> question are already mandatory, so any POSIX change would
> have no impact. We've already figured that the embedded
> equivalent of LSB-core has to have some changes as it's
> too "fat" - I hadn't twigged that these would be part of
> the subtraction, but that sort of information will emerge
> if the work on LSB-embedded ever actually happens.
And don't forget that these option removals have NOT yet been decided on
at POSIX. This is a very good reason to argue against the removal of
these two options in POSIX (though possibly joining them as a single one
might be another approach). Nevertheless, as Mats points out, we already
have the interfaces under these two options included.
Nick Stoughton Cell: 510 388 1413
USENIX Standards Liaison Fax: 510 548 5738
More information about the lsb-discuss