I can deal with uid_t, gid_t, and id_t being removed from the
list. Although I would prefer that they are not as I agree with the
earlier post that the reason they were arithmetic types in the earlier
standard was not to preserve the ability to make the types longer than
long, but rather shorter tha short. However, I will admit that the
standard can be read as allowing a type like long long to be used.
With pid_t, however, I just don't see it. It is now guaranteed to be
integral. It is only tied to id_t by saying that it will fit into an id_t,
which obviously allows it to be smaller. As far as mega clustering
applications of the type you describe, I don't see any reason you would
need to map every distrubuted process slice as a pid_t. From what I have
seen, it makes most sense to give each job/task a pid which looks up into
a table which has information on where the pieces of the job are running,
including their host and foreign process id.
On Tue, 13 Mar 2001, Donn Terry wrote:
> Thanks Don.
>
> To address your question at the end; although I could easily
> be wrong, based on what I know now, there are no changes needed
> to the current standard if uid_t, gid_t, id_t and pid_t are all
> allowed to be longer than long in the restricted environment.
> (I've been processing that question mentally as this discussion
> has progressed.) (The changes that were needed all fell out of
> the possibility of overflow in these types.) (There might be
> a change to the rationale needed to record this discussion, but
> to be frank it ain't gonna get written before the 23d, and probably
> not shortly thereafter, if I'm to do it.)
>
> As far as uid_t, gid_t, and id_t: that's a realtively immediate
> problem; I don't see a way out of providing "big" ones to some
> customers, and "mapping" of any form is not going to work because
> the values are persistent.
>
> For pid_t: the value is not (usefully) persistent, but I can easily
> imagine a monster "cluster of clusters" type of machine where for
> each processor to have a decent size "private" pid_t space, more
> than 32 bits will be needed. I tend to agree with Don (with the
> same "this is personal opinion only" disclaimer) that it'll be
> a while before that becomes real, but I believe that "a while" is
> less than 10 years, and is probably more like five. (yyyy@xxxx
> comes to mind as a precursor to another way besides the obvious
> "racks and racks of little boxes" way to get to this situation.)
>
> Donn
>
> -----Original Message-----
> From: Don Cragun [mailto:yyy@xxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, March 13, 2001 12:38 PM
> To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> Subject: Re: Comments on XBDd5 ERN 322
>
>
> Ted, Paul, Joe, Geoff, et al,
> I think we've been side tracked. The current draft of the
> revision requires that uid_t and gid_t be arithmetic types, that pid_t
> be a signed integer type, and that id_t be capable of holding a pid_t,
> uid_t, and gid_t values. This is the same requirement that was present
> in POSIX.1-1996.
> Since the revision has aligned with the 1999 C Standard, the
> revision allows a pid_t to be a long long int and allows id_t, gid_t,
> and uid_t to be complex floating types. There is no requirement here
> that a long be a 64-bit entity in order to have a 64-bit process ID in
> an implementation conforming to the revised standard.
> Geoff started a discussion of existing applications "needing" a
> "restricted" environment to be supplied by implementations conforming
> to the revised spec such that applications that conformed to the 1990
> POSIX standard wouldn't have to be ported to work under the 200x
> POSIX standard. This is a great goal, and Donn took the action item to
> rewrite various parts of the draft to try to make this hold together as
> much as possible. We discussed in the ballot resolution meeting in
> Alameda whether id_t, gid_t, uid_t, and pid_t should be added to the
> list guaranteed to fit in a long in these "restricted" environments
> even though there was no requirement for this for id_t, gid_t, and
> uid_t in the 1996 standard. We decided to try to make that guarantee
> unless we found a reason why it couldn't be done. The discussions here
> have made it clear that it can't be done without serious
> repercussions. Therefore, these types should be removed from the list
> of types guaranteed to fit in a long in the "restricted" environments
> provided by the revision.
> It can still be argued that pid_t is different from the others
> since the 1996 standard and the current draft require that pid_t be a
> signed integer type. In the 1996 standard, that meant that pid_t was
> no bigger than long int. In the revision, it could be signed long long
> int or an implementation specific signed longer int. Any application
> that assumes that pid_t will fit in a long (rather than an arbitrary
> width integer type) is not a conforming application according to the
> revised draft standard.
> Personally, for the next 5 years, I'm happy to guarantee that
> the operating systems my company provides won't break any applications
> that depend on getpid() returning an integer type that can be held in a
> long. (Note well that this is a personal guarantee; not an official
> statement of any kind by Sun Microsystems, Inc.) But, I'm not sure I'm
> willing to extend that guarantee for over a decade. Note that we are
> now performing the first revision of IEEE Std 1003.1-1990. When we
> move to a 128-bit architecture, it makes perfect sense to me that the
> type widths should be something like:
> char 8 bits
> short 16 bits
> int 32 bits
> long 64 bits
> long long 128 bits
> and I don't want to write a standard now that precludes this when the
> time comes. And, I don't want to declare now that I won't need to make
> pid_t a 128-bit entity.
> I fully expect that applications written to a 1990 (or even
> 1996) standard will be around for a while and should continue to
> function correctly on any POSIX.1-1990 conforming implemnentation. Any
> implementation that claims to conform to the 1990 standard must make
> this true. However, I do not expect that code written in 1990 can be
> recompiled with no changes and claim that it conforms to a new standard
> that we are writing now. When I get the point that I have to support
> 128-bit pid_t's, I will have to stop claiming to support SVID3, XPG3,
> UNIX '95, UNIX '98, POSIX.1-1990(and it various amendments) conforming
> applications. It shoulnd't mean that I won't be able to conform to
> POSIX.1-200x unless I artificially inflate a long to be 128 bits
> instead of using the logical long long that obviously fits this
> position so well.
> I've seen all the discussion about how long it will be before
> we have 128-bit hardware. I've also seen the discussions saying that
> we have to support applications that were written over 10 years ago
> without the possibility of them being ported to the current standard.
> I'm saying the transition to the current spec needs to start now; not
> in 2012, and certainly not never.
> I hope that at this point Donn can go back and give us one more
> pass on his proposed changes dropping the support for gid_t, id_t,
> pid_t, and uid_t being restricted to no wider than long. This will
> match what Geoff requested in his aardvark input and will give all of
> us something we should be able to live with.
>
> Thanks,
> Don
>
> >From yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx Tue Mar 13 10:24:39 2001
> >Resent-Date: 13 Mar 2001 18:22:39 -0000
> >From: Ted Baker <yyyyy@xxxxxxxxxxxxxx>
> >To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx, yyyyyy@xxxxxxxxxxx
> >Subject: Re: Comments on XBDd5 ERN 322
> >Resent-Message-ID: <yyyyyyyyyyyyyyyyy@xxxxxxx>
> >Resent-To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >Resent-From: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >X-Mailing-List: austin-group-l:archive/latest/2927
> >X-Loop: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >Resent-Sender: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >
> >This (uid_t and pid_t) is the second round of discussions under
> >the Austin Group where I've seen an effort to accomodate systems
> >that use 64-bit values (sizes, user id's, process id's, etc.) in
> >the OS API but do not have 64-bit long integers.
> >
> >I'm convinced that it is contrary to the interest of existing
> >POSIX/Unix users (including the US Government), application
> >developers, and the existing vendors or Unix-compliant operating
> >systems to adopt a standard that allows one to call such a system
> >"POSIX compliant".
> >
> >It is only logical that if applications (through the OS API) need
> >to work with 64-bit values, the long integer type will be at least
> >64 bits.
> >
> >Yes, I read the claims that somebody "needs" to support 64-bit
> >values in the API on a system with a 32-bit long integer type.
> >I'll accept that some vendor(s) may have decided they want to
> >support such an "oddball" environment, for some special need.
> >That does not justify breaking the usefulness of POSIX/Unix as a
> >portability standard for its existing market. The vendors who
> >want to support the oddball environment can do so, without calling
> >that environment "POSIX compliant".
> >
> >In the e-mails I have not seen any solid justification for this
> >being a true need. The need for 64-bit values in these (process
> >ID, etc.) API types itself is new, so it is appropriate that
> >systems that support the new 64-bit values also support a new
> >64-bit long integer type. One cannot argue that one needs binary
> >compatibility with legacy 32-bit binaries (or an old ABI), since
> >presumably those binaries were compiled to expect 32-bit values
> >for the types in question, and so would break if passed 64-bit
> >values (an new applications compiled to the old ABI would also
> >break).
> >
> >--Ted
> >
> >
>
>
--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.
yyyyyyy@xxxxxxxx toll-free: 888.771.3538 RTP area: 919.816.9901
|