From jre@radio Tue Mar 28 17:49:17 1995 Date: Tue, 28 Mar 1995 17:51:23 -0800 From: jre@radio (Joe E.) To: psarc@radio Subject: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: stevez@west Content-Length: 4943 I'm sponsoring this project for Steve Z.. The timer expires in one week, Tuesday April 4, at 18:00 PST. If there's no explicit de-railment by then, the project will be approved. Joe These would be public interfaces. PowerPC sysconfig Parameters 1. Introduction 1.1. Project/Component Working Name: Additional sysconfig Parameters 1.2. Name of Document Author/Supplier: Steve Z. 1.3. Date of This Document: 1/13/95 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC 2. Description The PowerPC Virtual Environment Architecture, Book II-AIM (which is one of the series of books defining the PowerPC architecture) says [section 3.1]: It is suggested that the operating system provide a service that allows an application program to obtain the following information. 1. Page size 2. Coherence block size 3. Granule sizes [typo for "size"] for reservations 4. An indicator of whether the processor has (a) a combined cache or no caches, or (b) some other cache configuration ... 5. Instruction cache size 6. Data cache size ... These parameters are needed for an application to make efficient use of some of the user-accessible instructions, notably those that preload, flush, invalidate, or clear cache blocks. For example, the cache block size would be useful on both PowerPC and SPARC for implementing the recently approved sync_instruction_memory() function. This project proposes to provide these parameters through the sysconf library function, which already exists. The ABI+ allocates a range of sysconf requests (_SC_* in /usr/include/sys/unistd.h) for system-reserved values (those greater than or equal to 500, two of which are already used in Solaris). We propose adding requests between 500 and 600 with generic names where they might be useful on other ISAs (e.g., SPARC), and some above 600, naming them with PowerPC-indicative names (_SC_PPC_*) where they are clearly PowerPC-specific, as shown below. Sysconf may return -1 and set errno, as specified in the manpage, for parameters which are meaningless, indeterminable, or deemed not useful on a particular ISA 3. External Requestor None 4. Opportunity Window/Exposure Should be available at FCS for PowerPC. Without the cache parameters, we cannot use the Data Cache Block Zero instruction, and all uses of the block invalidation and store instructions (e.g., for sync_instruction_memory()) must assume a worst-case 4-byte size. 5. Business Opportunity/Exposure N/A 6. Technical Description The following definitions will be added to /usr/include/sys/unistd.h and supported in the libc sysconf function: NAME VALUE MEANING ON PowerPC _SC_COHER_BLKSZ 503 Coherence block size _SC_SPLIT_CACHE 504 != 0 iff processor has a split cache _SC_ICACHE_SZ 505 Instruction cache size (bytes) _SC_DCACHE_SZ 506 Data cache size (bytes) _SC_ICACHE_LINESZ 507 Instruction cache line size _SC_DCACHE_LINESZ 508 Data cache line size _SC_ICACHE_BLKSZ 509 Block size invalidated by icbi _SC_DCACHE_BLKSZ 510 Block size for dcbz, dcbst, dcbf and dcbi _SC_DCACHE_TBLKSZ 511 Block size for dcbt and dcbtst (the block "touching" ops) _SC_ICACHE_ASSOC 512 Icache associativity (2 = 2-way...) _SC_DCACHE_ASSOC 513 Dcache associativity (2 = 2-way...) _SC_PPC_GRANULE_SZ 601 Granule size for reservations _SC_PPC_TB_TICKSPSECH 602 See below _SC_PPC_TB_TICKSPSECL 603 The concatenation of TB_TICKSPSECH (high half) and TB_TICKSPSECL (low half) specify the amount by which the Time Base is incremented in one second (not necessarily constant; current value is returned) Notes: 1. The PowerPC architecture specifies that all processors in an SMP must be identical with respect to these parameters. 2. If caches are not split, the same values are given for corresponding ICACHE and DCACHE parameters. 3. On PowerPC, if there is no instruction cache, the ICACHE_BLKSZ is the number of bytes zeroed by dcbz; similarly, if there is no data cache, DCACHE_TBLKSZ and DCACHE_BLKSZ are the number of bytes zeroed by dcbz. [No processors that I know of have DCACHE_TBLKSZ different from DCACHE_BLKSZ, but the architecture apparently makes the term "data cache block size" ambiguous!] The sysconf library function will obtain these values from the kernel using _sysconfig, as it does for many of the other _SC_* parameters. This requires adding similar _CONFIG_* definitions to /usr/include/sys/sysconfig.h and implementing the request in sysconfig.c in the kernel's undocumented (private) _sysconfig system call, again, under a PowerPC #ifdef. 7. Reference Documents None 8. Projected Availability 1Q95 9. Cost of Effort 10 staff days 10. Prototype Availability N/A 11. Prototype Cost N/A 12. Cost of Capital Resources None From shannon@datsun Wed Mar 29 00:39:33 1995 Date: Wed, 29 Mar 1995 00:38:53 -0800 From: shannon@datsun (Bill Shannon) To: jre@radio, psarc@radio Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: stevez@west Content-Length: 1879 The following definitions will be added to /usr/include/sys/unistd.h and supported in the libc sysconf function: NAME VALUE MEANING ON PowerPC _SC_COHER_BLKSZ 503 Coherence block size _SC_SPLIT_CACHE 504 != 0 iff processor has a split cache _SC_ICACHE_SZ 505 Instruction cache size (bytes) _SC_DCACHE_SZ 506 Data cache size (bytes) _SC_ICACHE_LINESZ 507 Instruction cache line size _SC_DCACHE_LINESZ 508 Data cache line size _SC_ICACHE_BLKSZ 509 Block size invalidated by icbi _SC_DCACHE_BLKSZ 510 Block size for dcbz, dcbst, dcbf and dcbi _SC_DCACHE_TBLKSZ 511 Block size for dcbt and dcbtst (the block "touching" ops) _SC_ICACHE_ASSOC 512 Icache associativity (2 = 2-way...) _SC_DCACHE_ASSOC 513 Dcache associativity (2 = 2-way...) _SC_PPC_GRANULE_SZ 601 Granule size for reservations _SC_PPC_TB_TICKSPSECH 602 See below _SC_PPC_TB_TICKSPSECL 603 The concatenation of TB_TICKSPSECH (high half) and TB_TICKSPSECL (low half) specify the amount by which the Time Base is incremented in one second (not necessarily constant; current value is returned) Most of these values are very poorly specified, and some are still described in PPC-specific terms. Presumably all this will be fixed in the real documentation. This must also imply some "KBI" interfaces to get this information from the PSM to the _sysconfig system call handler, right? Is there already a mechanism to do this or will you add such a mechanism? I assume this project also includes the effort to make the system return correct values for all these on all supported platforms. The TICKSPSEC[HL] is pretty gross. What is "the Time Base"? Isn't equivalent information available through the POSIX.4 timer interfaces? I don't understand what this is so I don't understand why it's PPC-specific. From sw.@dingus Wed Mar 29 09:26:33 1995 Date: Wed, 29 Mar 1995 09:26:04 -0800 From: sw.@dingus (Scott W.) To: jre@radio, psarc@radio Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: stevez@west Content-Length: 820 >This must also imply some "KBI" interfaces to get this information from >the PSM to the _sysconfig system call handler, right? Yes. >Is there already >a mechanism to do this or will you add such a mechanism? As far as I know the KBI group hasn't discussed such a mechanism yet. The groups can work together to propose an interface now, or (more likely I think) this will get implemented in the current source and eventually the KBI group will formalize the interface. The KBI group has lots of areas of interfaces to define and other projects are making changes now that will affect what the eventual interfaces will look like. Unless the nature of how things are exposed to userland affect the KBI interfaces, I think it's fine for projects to proceed without worrying much about the eventual KBI implementation. From stevez@bigboy74.West.Sun.COM Wed Mar 29 16:31:16 1995 Date: Wed, 29 Mar 1995 16:28:24 -0800 From: stevez@bigboy74.West.Sun.COM (Steve Z.) To: Joe.E.@Eng, psarc@radio.Eng.Sun.COM, Bill.Shannon@Eng Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: stevez@West Content-Length: 5593 > Most of these values are very poorly specified, and some are still described > in PPC-specific terms. Presumably all this will be fixed in the real > documentation. Below I indicate those which I think are pretty well understood with "U", and take a stab at defining the others better [the PowerPC architecture books are in some cases less than wonderful in their [ab]use of language]: _SC_COHER_BLKSZ 503 Coherence block size Putting together some of the PPC language: [Memory] Coherence refers to the ordering of writes to a single location. Memory coherence is managed in blocks called "coherence blocks". Their size is implementation-dependent, but is usually larger than a word and often the size of a cache block. Yep. Poorly specified. I wouldn't have included it except for the requirement in the architecture manual. U _SC_SPLIT_CACHE 504 != 0 iff processor has a split cache U _SC_ICACHE_SZ 505 Instruction cache size (bytes) U _SC_DCACHE_SZ 506 Data cache size (bytes) U _SC_ICACHE_LINESZ 507 Instruction cache line size U _SC_DCACHE_LINESZ 508 Data cache line size U _SC_ICACHE_BLKSZ 509 Block size invalidated by icbi U _SC_DCACHE_BLKSZ 510 Block size for dcbz, dcbst, dcbf and dcbi The only possible confusion that might be related to the above is the difference between "block" and "line". The block is the replacement unit, and the line is the associativity unit. That is, there's one tag per line, but there may be more than one block in a line, some of which may not be "valid". > _SC_DCACHE_TBLKSZ 511 Block size for dcbt and dcbtst > (the block "touching" ops) I'm surprised that they separated this from DCACHE_BLKSZ, especially since the "touching" ops are only "hints", but they did and suggested that OSs make it available as a separate parameter. U _SC_ICACHE_ASSOC 512 Icache associativity (2 = 2-way...) U _SC_DCACHE_ASSOC 513 Dcache associativity (2 = 2-way...) The items below are PowerPC specific (numbers above 600 in the proposal). Anyone who might need them know what they are. [More comment later on TICKS.] > _SC_PPC_GRANULE_SZ 601 Granule size for reservations > _SC_PPC_TB_TICKSPSECH 602 See below > _SC_PPC_TB_TICKSPSECL 603 The concatenation of TB_TICKSPSECH > (high half) and TB_TICKSPSECL > (low half) specify the amount > by which the Time Base is > incremented in one second > (not necessarily constant; > current value is returned) > This must also imply some "KBI" interfaces to get this information from > the PSM to the _sysconfig system call handler, right? Is there already > a mechanism to do this or will you add such a mechanism? I'd be willing to work with the KBI folks to establish this interface. > I assume this project also includes the effort to make the system > return correct values for all these on all supported platforms. The proposal says: Sysconf may return -1 and set errno, as specified in the manpage, for parameters which are meaningless, indeterminable, or deemed not useful on a particular ISA. One could argue that the existing ISAs don't need these values, as their caches aren't as exposed, and if they had been needed, someone would have added them before. Perhaps PSARC could provide some guidance here as to which platforms need which parameters. > The TICKSPSEC[HL] is pretty gross. What is "the Time Base"? Isn't > equivalent information available through the POSIX.4 timer interfaces? > I don't understand what this is so I don't understand why it's PPC-specific. It's PPC-specific because the Time Base is a 64-bit, user-readable (usually, see below) register defined by the PowerPC architecture. It has some unusual properties, including the possibility that the frequency can change (e.g., for power management). The Time Base is intended (here I'm paraphrasing the architecture book) for timing sequences of a few hundred instructions or for low-overhead time stamps for tracing. It was originally specified as user-program readable, but recently the architecture was modified to require an implementation to make it possible for the OS to disable user-read to avoid covert timing channels. Anyway, it will be readable by user programs on most systems, and apparently the PPC-powers-that-be didn't want to limit the frequency of update to 4GHZ, even though an architecture note recommends the use of the CPU clock frequency divided by 8, 16, or 32. With respect to POSIX.4, the Time Base provides a (much!) less portable (i.e., not portable beyond PPC!) but much more efficient way to do interval timing. It's more efficient if only because one doesn't have to do the ticks to nanoseconds conversion, but if an implementation requires a system call to get the POSIX times, it wouldn't even be close. In addition, there's the matter of resolution. All POSIX.4 guarantees is 20,000,000 nanosecond resolution! Even without the POSIX.4 extensions, a PPC program can get fast, high resolution time just by reading the Time Base, and the parameters that we're proposing just make it possible for the program to convert the value to seconds (assuming that the rate hasn't changed!). And if we (or anyone) does implement POSIX.4 for Solaris, the implementation would probably use the Time Base would would REQUIRE these parameters! By the way, USL says they will respond to the request for these parameters in a timely fashion. That they acknowledged the request and assigned someone to respond already (in less than 24 hours) is encouraging. Steve From shannon@datsun Wed Mar 29 17:09:00 1995 Date: Wed, 29 Mar 1995 17:08:15 -0800 From: shannon@datsun (Bill Shannon) To: jre@radio, psarc@radio, sw.@dingus Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: stevez@west Content-Length: 1184 From sw.@dingus Wed Mar 29 09:27:14 1995 From: sw.@dingus (Scott W.) To: jre@radio, psarc@radio Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: stevez@west >This must also imply some "KBI" interfaces to get this information from >the PSM to the _sysconfig system call handler, right? Yes. >Is there already >a mechanism to do this or will you add such a mechanism? As far as I know the KBI group hasn't discussed such a mechanism yet. The groups can work together to propose an interface now, or (more likely I think) this will get implemented in the current source and eventually the KBI group will formalize the interface. The KBI group has lots of areas of interfaces to define and other projects are making changes now that will affect what the eventual interfaces will look like. Unless the nature of how things are exposed to userland affect the KBI interfaces, I think it's fine for projects to proceed without worrying much about the eventual KBI implementation. So there must clearly be some Consolidation Private interfaces that are a part of this project, right? I guess I'm willing to ignore them for now. From sw.@dingus Thu Mar 30 10:38:59 1995 Date: Thu, 30 Mar 1995 10:38:26 -0800 From: sw.@dingus (Scott W.) To: jre@radio, psarc@radio Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: stevez@west Content-Length: 900 >So there must clearly be some Consolidation Private interfaces that >are a part of this project, right? I guess I'm willing to ignore them >for now. I'm not speaking for Steve, but I wanted to say some things from the KBI perspective (jek3, please correct me where wrong). With the breaking up of the kernel into the PIM (/kernel/genunix) and the PSM (/platform/`uname -i`/kernel/unix) a somewhat arbitrary interface was established between these two modules. Until KBI formalizes that interface I don't think calls across the interface need to be specified and approved. However, it certainly is useful for PSARC to point out to projects that they may be having an effect on the eventual KBI and should talk to the KBI group. In the areas where the KBI has already been approved by PSARC (such as vm), PSARC definitely should inquire if the project is attempting to change those interfaces. From shannon@datsun Tue Apr 4 17:07:48 1995 Date: Tue, 4 Apr 1995 17:06:51 -0700 From: shannon@datsun (Bill Shannon) To: Joe.E.@Eng, psarc@radio.Eng.Sun.COM, stevez@bigboy74.West.Sun.COM Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Content-Length: 875 From stevez@bigboy74.West.Sun.COM Wed Mar 29 16:30 PST 1995 The proposal says: Sysconf may return -1 and set errno, as specified in the manpage, for parameters which are meaningless, indeterminable, or deemed not useful on a particular ISA. One could argue that the existing ISAs don't need these values, as their caches aren't as exposed, and if they had been needed, someone would have added them before. Perhaps PSARC could provide some guidance here as to which platforms need which parameters. I would remove the "deemed not useful" clause and require you to provide the data for all supported platforms. There's probably some additional attributes (e.g., virtual vs. physical cache) needed to properly characterize the caches on all platofmrs we support. You might need to introduce some of them to make the other data useful. From stevez@bigboy74.West.Sun.COM Mon Apr 10 16:15:20 1995 Date: Mon, 10 Apr 1995 16:12:27 -0700 From: stevez@bigboy74.West.Sun.COM (Steve Z.) To: Bill.Shannon@Eng, psarc@Eng Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: joe.e.@Eng Content-Length: 2850 > From stevez@bigboy74.West.Sun.COM Wed Mar 29 16:30 PST 1995 > > The proposal says: > > Sysconf may return -1 and set errno, as specified in the > manpage, for parameters which are meaningless, indeterminable, > or deemed not useful on a particular ISA. > > One could argue that the existing ISAs don't need these values, > as their caches aren't as exposed, and if they had been needed, > someone would have added them before. Perhaps PSARC could > provide some guidance here as to which platforms need which > parameters. > > I would remove the "deemed not useful" clause and require you to provide > the data for all supported platforms. PowerPC caches are highly "exposed" in the user programming model. The best example of this is the "Data Cache Block Zero" instruction, which is logically equivalent to writing zeroes in an entire cache block, but of course is considerably faster because it doesn't have to read the data first, as would happen if you stored zero sequentially into each word of the block. This makes it useful for "bzero", and even the destination of "bcopy" operations. In addition, there are user code invocable cache-preload "touch" instructions, and instructions for forcing stores, flushing data cache blocks, and invalidating instruction cache blocks, some of which are needed by self-modifying code. User code could always assume a "worst case" (small) size, but this add inefficiency to already-PowerPC-specific code. Neither SPARC nor x86 exposes its caches to user-level instructions. On x86, we cannot reasonably determine the sizes of the cache or cache blocks. This varies with different implementations (e.g., a 486 from Intel may have a different cache organization than one from AMD, or even an earlier Intel model), even though the chips are interchangeable. Besides, there are no user-level instructions that are cache-aware, so there's no reason to provide the parameters on x86 in the first place. I believe that implementing these parameters on x86 would be time-consuming make-work with neglibible value, even if we were willing to take on the tracking of the various chips and making Solaris chip-aware, which I know we are not. The SPARC cache is not nearly as exposed as on PowerPC -- no instruction acts explicitly on a cache block. There may be some utility in implementing some of the "500-range" parameters on some SPARC platforms, but I hope that this will not be a requirement for the architecture in 1995/082 to be approved. It is not clear that the utility for SPARC warrants the effort, and certainly not for all the older systems. The proposal asks that the interfaces be approved for those platforms for which they are useful, using the already-possible "I don't know" response for the others unless/until they are implemented. Steve From c.@political Tue Apr 11 19:14:27 1995 Date: Tue, 11 Apr 1995 19:15:29 +0800 From: c.@political (Steve C.) To: psarc@Eng, stevez@bigboy74.West.Sun.COM Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: joe.e.@Eng Content-Length: 2315 >> One could argue that the existing ISAs don't need these values, >> as their caches aren't as exposed, and if they had been needed, >> someone would have added them before. Perhaps PSARC could >> provide some guidance here as to which platforms need which >> parameters. >> >> I would remove the "deemed not useful" clause and require you to provide >> the data for all supported platforms. I think that we can require that the interfaces being architected make sense for all platforms, not just PowerPC (and maybe PowerPC should be dropped from the title of the proposal), and I think that they do (except, of course, for the ones that are unique to the PowerPC). But I see requiring that they all return meaningful values (and not just EINVAL) on all platforms all in the same release as an implementation issue, not an architectural one. Clearly, PowerPC needs these interfaces, because there are non-privileged user-land instructions whose architected use depends upon knowledge of various cache parameters, and I would imagine that there will be PowerPC-specific portions of run-time libraries (and maybe even applications) that will need this information. x86 has no non-privileged user-land instructions whose architected use depends upon knowledge of various cache parameters; no run-times need this information. SPARC V8 has none, and SPARC V9 has two, sort of. (FLUSH, which operates on a doubleword in V8, operates on "at least" a doubleword in V9, but the actual size isn't architecturally tied to cache parameters. PREFETCH operates on a "data block", whose size and alignment is implementation dependent, but is at least 64 bytes in length and aligned on at least a 64-byte boundary.) For SPARC V9, I'd probably want to add _SC_SPARCV9_PREFETCH_SIZE and _SC_SPARCV9_FLUSH_SIZE to Steve Z.'s list. But that's not this proposal, and I'm not proposing it now. To sum it up, I see Z.'s proposal as a step in a succession of projects. I see this step as complete in and of itself. It does not preclude future steps that would return values for these requests on other architectures (those projects would probably qualify for self-approval), nor does it preclude future steps that would add new requests for new needs (those projects would probably be fast-trackable). --Steve From shannon@datsun Wed Apr 12 00:28:55 1995 Date: Wed, 12 Apr 1995 00:27:55 -0700 From: shannon@datsun (Bill Shannon) To: c.@political, psarc@Eng, stevez@bigboy74.West.Sun.COM Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: joe.e.@Eng Content-Length: 744 From c.@political Tue Apr 11 19:14:37 1995 I think that we can require that the interfaces being architected make sense for all platforms, not just PowerPC (and maybe PowerPC should be dropped from the title of the proposal), and I think that they do (except, of course, for the ones that are unique to the PowerPC). But I see requiring that they all return meaningful values (and not just EINVAL) on all platforms all in the same release as an implementation issue, not an architectural one. Well, you may be right that this is not an architectural issue, but I feel pretty strongly that this is not the right choice for the product. If no one else believes this is an architectural issue, I'll drop it and deal with the SC. From c.@political Wed Apr 12 11:20:04 1995 Date: Wed, 12 Apr 1995 11:21:02 +0800 From: c.@political (Steve C.) To: psarc@Eng, stevez@bigboy74.West.Sun.COM Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: joe.e.@Eng Content-Length: 1391 >From shannon@datsun Wed Apr 12 00:30 PDT 1995 > > From c.@political Tue Apr 11 19:14:37 1995 > > I think that we can require that the interfaces being architected make > sense for all platforms, not just PowerPC (and maybe PowerPC should be > dropped from the title of the proposal), and I think that they do > (except, of course, for the ones that are unique to the PowerPC). But > I see requiring that they all return meaningful values (and not just > EINVAL) on all platforms all in the same release as an implementation > issue, not an architectural one. > >Well, you may be right that this is not an architectural issue, >but I feel pretty strongly that this is not the right choice >for the product. In the best of all possible worlds, the implementation of thes interfaces would appear simultaneously on all platforms. And if they were really significant to all platforms, I'd insist on it, too. However, they are mainly of value to PowerPC, and I don't think anyone is going to be terribly bent out of shape that they return useful values on PowerPC first, and not on others. >If no one else believes this is an architectural issue, I'll drop >it and deal with the SC. I would recommend to the SC that they start a project to get them to return useful values on other platforms, but I don't see the lack of simultaneous delivery as a show-stopper in this case. --Steve From shannon@datsun Wed Apr 12 12:21:47 1995 Date: Wed, 12 Apr 1995 12:20:31 -0700 From: shannon@datsun (Bill Shannon) To: c.@political, psarc@Eng, stevez@bigboy74.West.Sun.COM Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Cc: joe.e.@Eng Content-Length: 1070 In the best of all possible worlds, the implementation of thes interfaces would appear simultaneously on all platforms. And if they were really significant to all platforms, I'd insist on it, too. However, they are mainly of value to PowerPC, and I don't think anyone is going to be terribly bent out of shape that they return useful values on PowerPC first, and not on others. If it wasn't for the fact that I know people have asked for information of this sort on SPARC, I might agree with you. So far we've put them off by telling them "you don't really need to know that". Now we're actually giving them a legitimate way to ask the question, but we're not providing them an answer. It just seems wrong. >If no one else believes this is an architectural issue, I'll drop >it and deal with the SC. I would recommend to the SC that they start a project to get them to return useful values on other platforms, but I don't see the lack of simultaneous delivery as a show-stopper in this case. Ok, please communicate this issue to the SC and cc PSARC. From jre@radio Wed Apr 12 14:06:21 1995 Date: Wed, 12 Apr 1995 14:05:38 -0700 From: jre@radio (Joe E.) To: c.@political, psarc@Eng, stevez@bigboy74.West.Sun.COM, shannon@datsun Subject: Re: fast-track PowerPC sysconfig parameters PSARC/1995/082 Content-Length: 70 This project was approved at today's PSARC meeting. Thanks, Joe From c.@political Wed Apr 12 20:50:31 1995 Date: Wed, 12 Apr 1995 20:51:43 +0800 From: c.@political (Steve C.) To: ossc@benet Subject: Concerning PowerPC sysconfig parameters (fast-track PSARC/1995/082) Cc: psarc@sac, steve.z.@West, jre@Eng Content-Length: 752 This project proposed new sysconfig requests that apply to all architectures, but only implemented values for PowerPC (on other architectures, EINVAL is returned). While PSARC approved this project, it would like to see another project started that would implement values on the other architectures; it is not a requirement that both projects be delivered simultaneously. (That is, 1995/082 would not depend on this other project.) Therefore, PSARC recommends to the OSSC that you start a project to implement values for SPARC and x86 for the new sysconfig parameters introduced by PSARC/1995/082. This email is in lieu of an opinion, as no opinion is written for fast-tracks. Details can be gleaned from /shared/sac/PSARC/1995/082/mail. --Steve From roland.mainz@nrubsig.org Wed May 6 19:54:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n472sd2C008114 for ; Wed, 6 May 2009 19:54:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n472sXGC029298; Thu, 7 May 2009 03:54:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ900E0J6QXUH00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ900BSP6QX2670@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n472lgI1023995; Thu, 07 May 2009 02:54:32 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-1721496; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-524814; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-5769081; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mx.arcor.de (Postfix) with ESMTP id E20561AF2FA; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id CA18723D2B5; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-212-156.pools.arcor-ip.net [94.219.212.156]) by mail-in-11.arcor-online.net (Postfix) with ESMTPS id 27B9EE38FE; Thu, 07 May 2009 04:16:48 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n472GkrR002190; Thu, 07 May 2009 04:16:47 +0200 (CEST) Date: Thu, 07 May 2009 04:16:46 +0200 From: Roland Mainz Subject: Requesting ARC cases 1993/685, 1994/188, 1994/196, 1994/197, 1994/302, 1995/077, 1995/082, 1995/153 Sender: gisburn@jupiterb48.nrubsig.org To: opensolaris-arc@opensolaris.org Cc: Bonnie Corwin , "PSARC-EXT@sun.com" , emerging-platforms-discuss@opensolaris.org Message-id: <4A02448E.1AC9B6BA@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-11.arcor-online.net 27B9EE38FE X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ x_sac_archived: PSARC/1993/685 x_sac_archived: PSARC/1994/188 x_sac_archived: PSARC/1994/196 x_sac_archived: PSARC/1994/197 x_sac_archived: PSARC/1994/302 x_sac_archived: PSARC/1995/077 Status: RO Content-Length: 704 hi! ---- I'd like to request to open the following ARC cases for publish access: PSARC 1993/685 PowerPC_ABI PSARC 1994/188 Solaris Kernel for PowerPC PSARC 1994/196 PowerPC Header Files PSARC 1994/197 PowerPC Commands PSARC 1994/302 PowerPC_Booting PSARC 1995/077 processor_info(2) binding for PowerPC and future ISAs PSARC 1995/082 PowerPC sysconfig parameters PSARC 1995/153 PPC installboot We need this materials as template for a set of ARC casess to specify support for a new architecture/hardware platform... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)