From sacadmin Mon Aug 16 12:02:50 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Aug 2004 15:02:30 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: frank.dimambro@Sun.COM Subject: 2004/614 Kernel-Level Atomic Operations Status: RO Content-Length: 4438 Lines: 124 I'm sponsoring this fast-track request for Frank Dimambro. The timer is set to 08/23/2004. There's a prototype atomic_ops(9F) man page in the case directory as atomic_ops.9f. Similar changes to the existing atomic_ops(3C) would be needed. Overview ======== "User-Level Atomic Operations" (PSARC/2000/505) defines a collection of atomic instructions available to multithreaded userland applications. These functions have existed as part of the kernel for a similar period of time. The kernel versions have neither an ARC case nor a man page, and hence it's assumed they are consolidation private. The ability to do atomic instructions in the kernel is as useful to kernel software developers as the 'libc' versions are to user level application developers. There are some atomic operations in the kernel that are also useful but are not defined in 2000/505. These should also be considered for an Evolving classification. This case proposes to reclassify all the atomic operation functions in the of the publicly useful (see below) interfaces to "Evolving". It will also make sure that all the atomic functions defined in the kernel and being made public by this case are added to 'libc' such that what is available in the kernel is also available to the application layer. These extra user-land functions added by this project are: atomic_or_long, atomic_and_long, cas32, caslong, cas64, casptr, cas8, atomic_set_long_excl, and atomic_clear_long_excl. The requested release binding is "Minor". Details ======= Over the years the following functions have proved to be very useful to the NSPG consolidation to reduce cost of points of serialization in kernel device drivers. This case would like to make these interfaces publicly available, and assign a stability level of Evolving. Man pages for all of the interfaces being classified as Evolving are available in the case directory. Publicly Useful (classified as Evolving) ================= The following atomic operation functions can be used in device drivers to implement various synchronization mechanisms that cannot be easily implemented via semaphores, condition variables, mutexes or reader/writer locks. atomic_add_16 Atomically 'add' a 16 bit value. atomic_add_32 Atomically 'add' a 32 bit value. atomic_add_long Atomically 'add' a long bit value. atomic_add_64 Atomically 'add' a 64 bit value. atomic_or_uint Atomically 'or' a unsigned int value. atomic_or_32 Atomically 'or' a 32 bit value. atomic_or_long Atomically 'or' a long value. atomic_and_uint Atomically 'and' a unsigned int value. atomic_and_32 Atomically 'and' a 32 bit value. atomic_and_long Atomically 'and' a long value. atomic_add_16_nv Atomically 'add' a 16 bit value and return the result as a function result. atomic_add_32_nv Atomically 'add' a 32 bit value and return the result as a function result. atomic_add_long_nv Atomically 'add' a long value and return the result as a function result. atomic_add_64_nv Atomically 'add' a 64 bit value and return the result as a function result. cas32 Atomically compare a given 32 bit value with a comparative 32 bit value, if equal they are equal apply a new value, otherwise do nothing. Always return the old value. caslong Atomically compare a given long value with a comparative long value, if equal they are equal apply a new value, otherwise do nothing. Always return the old value. cas64 Atomically compare a given 64 bit value with a comparative 64 bit value, if equal they are equal apply a new value, otherwise do nothing. Always return the old value. casptr Atomically compare a given pointer value with a comparative pointer value, if equal they are equal apply a new value, otherwise do nothing. Always return the old value. cas8 Atomically compare a given 8 bit value with a comparative 8 bit value, if equal they are equal apply a new value, otherwise do nothing. Always return the old value. atomic_set_long_excl Perform an exclusive atomic bit set on a target. Returns 0 if bit was successfully set, or -1 if the bit was already set. atomic_clear_long_excl Perform an exclusive atomic bit clear on a target. Returns 0 if bit was successfully cleared, or -1 if the bit was already cleared. From sacadmin Mon Aug 16 14:52:42 2004 Date: Mon, 16 Aug 2004 22:52:19 +0100 From: Phil Harman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: psarc@sac.sfbay.sun.com, frank.dimambro@sun.com Subject: Re: 2004/614 Kernel-Level Atomic Operations Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020806080402080202010203" Status: O Content-Length: 9883 Lines: 218 This is a cryptographically signed message in MIME format. --------------ms020806080402080202010203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is good news. But I think we need a little more work. Siebel are very excited by atomic_ops(3c), but are already asking for an atomic_exchange() - i.e. SWAP in SPARC. I think we should include this if atall possible. I am a little surprised/disappointed that we haven't continued the atomic_* theme throughout. Can we reconsider this please? In a sense I don't care so much what we do for the kernel, but I do think the atomic_ops(3c) APIs should try to offer a degree of uniformity. Thanks, Phil James Carlson wrote: >I'm sponsoring this fast-track request for Frank Dimambro. The timer >is set to 08/23/2004. > >There's a prototype atomic_ops(9F) man page in the case directory as >atomic_ops.9f. Similar changes to the existing atomic_ops(3C) would >be needed. > > >Overview >======== > > "User-Level Atomic Operations" (PSARC/2000/505) defines a > collection of atomic instructions available to multithreaded > userland applications. These functions have existed as part > of the kernel for a similar period of time. The kernel > versions have neither an ARC case nor a man page, and hence > it's assumed they are consolidation private. > > The ability to do atomic instructions in the kernel is as > useful to kernel software developers as the 'libc' versions > are to user level application developers. > > There are some atomic operations in the kernel that are also > useful but are not defined in 2000/505. These should also be > considered for an Evolving classification. > > This case proposes to reclassify all the atomic operation > functions in the of the publicly useful (see > below) interfaces to "Evolving". > > It will also make sure that all the atomic functions defined > in the kernel and being made public by this case are added to > 'libc' such that what is available in the kernel is also > available to the application layer. These extra user-land > functions added by this project are: atomic_or_long, > atomic_and_long, cas32, caslong, cas64, casptr, cas8, > atomic_set_long_excl, and atomic_clear_long_excl. > > The requested release binding is "Minor". > >Details >======= > > Over the years the following functions have proved to be very > useful to the NSPG consolidation to reduce cost of points of > serialization in kernel device drivers. > > This case would like to make these interfaces publicly > available, and assign a stability level of Evolving. > > Man pages for all of the interfaces being classified as > Evolving are available in the case directory. > >Publicly Useful (classified as Evolving) >================= > > The following atomic operation functions can be used in device > drivers to implement various synchronization mechanisms that > cannot be easily implemented via semaphores, condition > variables, mutexes or reader/writer locks. > > atomic_add_16 Atomically 'add' a 16 bit value. > > atomic_add_32 Atomically 'add' a 32 bit value. > > atomic_add_long Atomically 'add' a long bit value. > > atomic_add_64 Atomically 'add' a 64 bit value. > > atomic_or_uint Atomically 'or' a unsigned int value. > > atomic_or_32 Atomically 'or' a 32 bit value. > > atomic_or_long Atomically 'or' a long value. > > atomic_and_uint Atomically 'and' a unsigned int value. > > atomic_and_32 Atomically 'and' a 32 bit value. > > atomic_and_long Atomically 'and' a long value. > > atomic_add_16_nv Atomically 'add' a 16 bit value and return the result as a function result. > > atomic_add_32_nv Atomically 'add' a 32 bit value and > return the result as a function result. > > atomic_add_long_nv Atomically 'add' a long value and > return the result as a function result. > > atomic_add_64_nv Atomically 'add' a 64 bit value and > return the result as a function result. > > cas32 Atomically compare a given 32 bit value > with a comparative 32 bit value, if equal > they are equal apply a new value, otherwise > do nothing. Always return the old value. > > caslong Atomically compare a given long value > with a comparative long value, if equal > they are equal apply a new value, otherwise > do nothing. Always return the old value. > > cas64 Atomically compare a given 64 bit value > with a comparative 64 bit value, if equal > they are equal apply a new value, otherwise > do nothing. Always return the old value. > > casptr Atomically compare a given pointer value > with a comparative pointer value, if equal > they are equal apply a new value, otherwise > do nothing. Always return the old value. > > cas8 Atomically compare a given 8 bit value > with a comparative 8 bit value, if equal > they are equal apply a new value, otherwise > do nothing. Always return the old value. > > atomic_set_long_excl Perform an exclusive atomic bit set > on a target. Returns 0 if bit was successfully > set, or -1 if the bit was already set. > > atomic_clear_long_excl Perform an exclusive atomic bit clear > on a target. Returns 0 if bit was successfully > cleared, or -1 if the bit was already cleared. > > --------------ms020806080402080202010203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8TCC AtMwggI8oAMCAQICAwvdQDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzA4MTAzNjI0WhcNMDUwMzA4MTAzNjI0 WjBFMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNw aGlsLmhhcm1hbkBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7gNO oT24HcLfRo6VbcbW7pko1d8YEW6EydJmiFSq9tXPJfXmsBUYC6IyR1tzo32fog8O/Xcw2frA 2ray2YNl4TvdVR0PnRaSOhf7BcHlCC+vjHHENwOFiO0edksevPamOnYUKBxcHJRlf0tyXsgJ /u+zR8zmkryr8P8U2igM8iyt+wFAf+apniB2QJAMXNGEZ07v4EIZb2OgGpTbLWzcXdBMEwnY 3gyPA8gH4RLL/dU/tcll2sNacb8CBeecphgy/HAFjLbM2G3/eGwrbpuyo0Gu7ZEgtwXaazaK oYH3bYpTY92NVTobkKKG6KAzxU5eLek7MOSuVd6PAxiPLAVcyQIDAQABozAwLjAeBgNVHREE FzAVgRNwaGlsLmhhcm1hbkBzdW4uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQAD gYEAsthm7K1edgeby8ThOb6QgZSkFIMJk8dFjxqqYNMytZsafq/Uw77Aqht+JUPoffWLpub2 4ix9BbU5CIQMNt+iUrmTPmcP5qMJsLLnWrL3AfZ9iLWxQjzaDzVFbd1g/Yluq79Q9NsaCKmn YjzsUKyBb8U+S3rUzCbT0HTFr5/JhOcwggLTMIICPKADAgECAgML3UAwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MDMwODEwMzYyNFoXDTA1MDMwODEwMzYyNFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWls IE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTcGhpbC5oYXJtYW5Ac3VuLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAO4DTqE9uB3C30aOlW3G1u6ZKNXfGBFuhMnSZohUqvbV zyX15rAVGAuiMkdbc6N9n6IPDv13MNn6wNq2stmDZeE73VUdD50WkjoX+wXB5Qgvr4xxxDcD hYjtHnZLHrz2pjp2FCgcXByUZX9Lcl7ICf7vs0fM5pK8q/D/FNooDPIsrfsBQH/mqZ4gdkCQ DFzRhGdO7+BCGW9joBqU2y1s3F3QTBMJ2N4MjwPIB+ESy/3VP7XJZdrDWnG/AgXnnKYYMvxw BYy2zNht/3hsK26bsqNBru2RILcF2ms2iqGB922KU2PdjVU6G5CihuigM8VOXi3pOzDkrlXe jwMYjywFXMkCAwEAAaMwMC4wHgYDVR0RBBcwFYETcGhpbC5oYXJtYW5Ac3VuLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALLYZuytXnYHm8vE4Tm+kIGUpBSDCZPHRY8a qmDTMrWbGn6v1MO+wKobfiVD6H31i6bm9uIsfQW1OQiEDDbfolK5kz5nD+ajCbCy51qy9wH2 fYi1sUI82g81RW3dYP2Jbqu/UPTbGgipp2I87FCsgW/FPkt61Mwm09B0xa+fyYTnMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/ DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODE2MjE1MjE5WjAjBgkqhkiG 9w0BCQQxFgQU7rIN7lVGHfS/r7Cyj5B+AygAN9gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwvdQDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwDQYJKoZIhvcNAQEBBQAEggEA 3zG9+Phe2Z2pinSxObYxkBlWEaMbnQ6qMde1TbeJoOS6tHTQv3HYyePNwnM6yPN6r6l5a7TH egZGOv768kiWjnKddeF1r2BQfvM6GptsTGfPAJAKh0nTziO+wIL0CcxoHqS3VThvN07it1Rm US9TqddGThGvZVUM99R9jbTNjrnNLSNs424u9LcRZoTJNk+HyGfFrhNnW8CIGHIol9bFkMyC GuFqlDKrANP9jW4PA3YEaeUvAurwqwTx4SsFUUVsBAFrQTQWO63jpyXr1JWyijeW0u/SPEru FZsBQcXOSYT3wptQZbAgB7ztGXwKLVxwFSpP1J/2Fj2ttgI3kRBiCgAAAAAAAA== --------------ms020806080402080202010203-- From sacadmin Tue Aug 17 04:20:38 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Aug 2004 07:20:16 -0400 From: James Carlson To: Phil Harman Cc: psarc@sac.sfbay.sun.com, Frank.Dimambro@Sun.COM Subject: Re: 2004/614 Kernel-Level Atomic Operations Status: O Content-Length: 1590 Lines: 41 Phil Harman writes: > This is good news. But I think we need a little more work. > > Siebel are very excited by atomic_ops(3c), but are already asking for an > atomic_exchange() - i.e. SWAP in SPARC. I think we should include this > if atall possible. That sounds like an RFE to me. There isn't one in user space or the kernel, as far as I know, though it'd be easy to do: uint32_t atomic_exchange_32(uint32_t *target, uint32_t value) { uint32_t old_value; do { old_value = *target; } while (cas32(target, old_value, value) != old_value); return (old_value); } > I am a little surprised/disappointed that we haven't continued the > atomic_* theme throughout. Can we reconsider this please? In a sense I > don't care so much what we do for the kernel, but I do think the > atomic_ops(3c) APIs should try to offer a degree of uniformity. The "Compare And Swap" moniker has a long history. There's a 'cs' instruction on 370 that does the same basic thing as the 'cas' instruction on SPARC and 'cmpxchgl' on x86. Putting "atomic" in front of "compare and swap" seems redundant to me, as there's really only one kind of cas that's ever useful. (For what it's worth, AIX's libc has long had a compare_and_swap() function call. And I'm really looking forward to that rumored port back to PPC, as I really dig lwarx/stwcx. They're more fun than cas.) -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Aug 17 04:43:41 2004 Date: Tue, 17 Aug 2004 12:43:05 +0100 From: Phil Harman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: psarc@sac.sfbay.sun.com, Frank.Dimambro@sun.com Subject: Re: 2004/614 Kernel-Level Atomic Operations Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060401020200020506020009" Status: O Content-Length: 7365 Lines: 147 This is a cryptographically signed message in MIME format. --------------ms060401020200020506020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit James Carlson wrote: >Phil Harman writes: > > >>This is good news. But I think we need a little more work. >> >>Siebel are very excited by atomic_ops(3c), but are already asking for an >>atomic_exchange() - i.e. SWAP in SPARC. I think we should include this >>if atall possible. >> >> Please note that I will continue to restict my comments to atomic_ops(3c). I really don't care so much about what we do in the kernel. Too many ISVs are writing their own atomic code (and I get asked too often to debug it, because they often get it wrong). It is important that atomic_ops(3c) covers as many meaningful cases as possible, and with near optimal performance. Otherwise, ISVs will continue to write their own atomics (and some of them will continue to get it wrong). >That sounds like an RFE to me. There isn't one in user space or the >kernel, as far as I know, though it'd be easy to do: > >uint32_t >atomic_exchange_32(uint32_t *target, uint32_t value) >{ > uint32_t old_value; > > do { > old_value = *target; > } while (cas32(target, old_value, value) != old_value); > return (old_value); >} > > Sorry, but this just doesn't cut it. I know of people who will want a simple SWAP - without the possiblity of a spin. Indeed out own mutex_unlock(3c) relies on an inline function to the same, for example from usr/src/lib/libc/sparcv9/threads/sparcv9.il ... .inline swap32, 0 swap [%o0], %o1 mov %o1, %o0 .end >>I am a little surprised/disappointed that we haven't continued the >>atomic_* theme throughout. Can we reconsider this please? In a sense I >>don't care so much what we do for the kernel, but I do think the >>atomic_ops(3c) APIs should try to offer a degree of uniformity. >> >> > >The "Compare And Swap" moniker has a long history. There's a 'cs' >instruction on 370 that does the same basic thing as the 'cas' >instruction on SPARC and 'cmpxchgl' on x86. > >Putting "atomic" in front of "compare and swap" seems redundant to me, >as there's really only one kind of cas that's ever useful. > > From the kernel perspective I agree, however, I believe ISV adoption of these user level APis will be easier if we keep the naming consistent. We haven't shipped atomic_ops(3c) in a revenue release yet. Please, let's take the opportunity to make it as easy for the ISVs as possible. >(For what it's worth, AIX's libc has long had a compare_and_swap() >function call. And I'm really looking forward to that rumored port >back to PPC, as I really dig lwarx/stwcx. They're more fun than cas.) > > --------------ms060401020200020506020009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8TCC AtMwggI8oAMCAQICAwvdQDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzA4MTAzNjI0WhcNMDUwMzA4MTAzNjI0 WjBFMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNw aGlsLmhhcm1hbkBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7gNO oT24HcLfRo6VbcbW7pko1d8YEW6EydJmiFSq9tXPJfXmsBUYC6IyR1tzo32fog8O/Xcw2frA 2ray2YNl4TvdVR0PnRaSOhf7BcHlCC+vjHHENwOFiO0edksevPamOnYUKBxcHJRlf0tyXsgJ /u+zR8zmkryr8P8U2igM8iyt+wFAf+apniB2QJAMXNGEZ07v4EIZb2OgGpTbLWzcXdBMEwnY 3gyPA8gH4RLL/dU/tcll2sNacb8CBeecphgy/HAFjLbM2G3/eGwrbpuyo0Gu7ZEgtwXaazaK oYH3bYpTY92NVTobkKKG6KAzxU5eLek7MOSuVd6PAxiPLAVcyQIDAQABozAwLjAeBgNVHREE FzAVgRNwaGlsLmhhcm1hbkBzdW4uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQAD gYEAsthm7K1edgeby8ThOb6QgZSkFIMJk8dFjxqqYNMytZsafq/Uw77Aqht+JUPoffWLpub2 4ix9BbU5CIQMNt+iUrmTPmcP5qMJsLLnWrL3AfZ9iLWxQjzaDzVFbd1g/Yluq79Q9NsaCKmn YjzsUKyBb8U+S3rUzCbT0HTFr5/JhOcwggLTMIICPKADAgECAgML3UAwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MDMwODEwMzYyNFoXDTA1MDMwODEwMzYyNFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWls IE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTcGhpbC5oYXJtYW5Ac3VuLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAO4DTqE9uB3C30aOlW3G1u6ZKNXfGBFuhMnSZohUqvbV zyX15rAVGAuiMkdbc6N9n6IPDv13MNn6wNq2stmDZeE73VUdD50WkjoX+wXB5Qgvr4xxxDcD hYjtHnZLHrz2pjp2FCgcXByUZX9Lcl7ICf7vs0fM5pK8q/D/FNooDPIsrfsBQH/mqZ4gdkCQ DFzRhGdO7+BCGW9joBqU2y1s3F3QTBMJ2N4MjwPIB+ESy/3VP7XJZdrDWnG/AgXnnKYYMvxw BYy2zNht/3hsK26bsqNBru2RILcF2ms2iqGB922KU2PdjVU6G5CihuigM8VOXi3pOzDkrlXe jwMYjywFXMkCAwEAAaMwMC4wHgYDVR0RBBcwFYETcGhpbC5oYXJtYW5Ac3VuLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALLYZuytXnYHm8vE4Tm+kIGUpBSDCZPHRY8a qmDTMrWbGn6v1MO+wKobfiVD6H31i6bm9uIsfQW1OQiEDDbfolK5kz5nD+ajCbCy51qy9wH2 fYi1sUI82g81RW3dYP2Jbqu/UPTbGgipp2I87FCsgW/FPkt61Mwm09B0xa+fyYTnMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/ DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODE3MTE0MzA1WjAjBgkqhkiG 9w0BCQQxFgQUmuycD4NAWBSgoFd7ZWCRZ6ErlRIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwvdQDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwDQYJKoZIhvcNAQEBBQAEggEA Rh43HsVxpg2QKcldl1CGrVZRxjZqQ6nprFe36MIQ5GjwVLxVCY9es4xlfiEz1X22D3mqXeMT IrJOX3Sz11MS2NzpK3lTX0yLRKMCQRn1af6nceVzTZVw39heN8BgkJeBFzqlTOpuS+G7fEoz BHspZZ209NMVQaDVRbWiGoFgD1gTq8jrFMFa4va/kEzxSt8hVc7o85rSkPfhmTD9qUKCHjdr gKRYmUffgALHJ3b95CbU5/XUY7iHtDi5KDhpi5TeIgcN8mCaTAmkOp3irwheVAjjD3QBSkAc tnRDgh0Hs3HfJOeXhzvo1l3hntJaHGndw5xiYfddCFvzDASleYleAgAAAAAAAA== --------------ms060401020200020506020009-- From sacadmin Tue Aug 17 04:56:56 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Aug 2004 07:56:35 -0400 From: James Carlson To: Phil Harman Cc: psarc@sac.sfbay.sun.com, Frank.Dimambro@Sun.COM Subject: Re: 2004/614 Kernel-Level Atomic Operations Status: O Content-Length: 1499 Lines: 32 Phil Harman writes: > Sorry, but this just doesn't cut it. I know of people who will want a > simple SWAP - without the possiblity of a spin. Indeed out own > mutex_unlock(3c) relies on an inline function to the same, for example > from usr/src/lib/libc/sparcv9/threads/sparcv9.il ... I don't think the implementation is actually architecturally interesting. The interesting point is that there isn't such a function defined in kernel or user space today, so this case doesn't cover it. It sounds like a good RFE that someone should file, evaluate properly, and implement. > >Putting "atomic" in front of "compare and swap" seems redundant to me, > >as there's really only one kind of cas that's ever useful. > > > > > From the kernel perspective I agree, however, I believe ISV adoption of > these user level APis will be easier if we keep the naming consistent. > We haven't shipped atomic_ops(3c) in a revenue release yet. Please, > let's take the opportunity to make it as easy for the ISVs as possible. Part of the point of the case was to avoid having the kernel and user space functions for these primitives diverge in name. I would *not* want to have, for example, atomic_cas_32() in user space and cas32() in the kernel. That seems gratuitous to me. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Aug 17 05:11:13 2004 Date: Tue, 17 Aug 2004 13:10:42 +0100 From: Phil Harman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: psarc@sac.sfbay.sun.com, Frank.Dimambro@sun.com Subject: Re: 2004/614 Kernel-Level Atomic Operations Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020803040303080808050904" Status: O Content-Length: 6773 Lines: 130 This is a cryptographically signed message in MIME format. --------------ms020803040303080808050904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit James Carlson wrote: >Phil Harman writes: > > >>Sorry, but this just doesn't cut it. I know of people who will want a >>simple SWAP - without the possiblity of a spin. Indeed out own >>mutex_unlock(3c) relies on an inline function to the same, for example >>from usr/src/lib/libc/sparcv9/threads/sparcv9.il ... >> >> > >I don't think the implementation is actually architecturally >interesting. > > Indeed not. I was just quoting chapter and verse to underline that if we need it, why do we think our ISVs don't? >The interesting point is that there isn't such a function defined in >kernel or user space today, so this case doesn't cover it. It sounds >like a good RFE that someone should file, evaluate properly, and >implement. > > I'd just hoped for a bit more "yes we can do that too while we're at it". Do we have a business case for each and every API in atomic_ops(3c)? >>>Putting "atomic" in front of "compare and swap" seems redundant to me, >>>as there's really only one kind of cas that's ever useful. >>> >>> >>> >>> >> From the kernel perspective I agree, however, I believe ISV adoption of >>these user level APis will be easier if we keep the naming consistent. >>We haven't shipped atomic_ops(3c) in a revenue release yet. Please, >>let's take the opportunity to make it as easy for the ISVs as possible. >> >> > >Part of the point of the case was to avoid having the kernel and user >space functions for these primitives diverge in name. I would *not* >want to have, for example, atomic_cas_32() in user space and cas32() >in the kernel. That seems gratuitous to me. > > But I would expect that from a kernel engineer :) Do we really want ISVs to care about the vestigual organs of the kernel? I note that we already diverge on many other APIs (e.g. thread_create / thr_create, mutex_enter / mutex_lock, etc.) so what't the big deal? atomic_ops(3c) is something completely new in S10 for ISVs. Why screw it up from the start? Phil --------------ms020803040303080808050904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8TCC AtMwggI8oAMCAQICAwvdQDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzA4MTAzNjI0WhcNMDUwMzA4MTAzNjI0 WjBFMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNw aGlsLmhhcm1hbkBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7gNO oT24HcLfRo6VbcbW7pko1d8YEW6EydJmiFSq9tXPJfXmsBUYC6IyR1tzo32fog8O/Xcw2frA 2ray2YNl4TvdVR0PnRaSOhf7BcHlCC+vjHHENwOFiO0edksevPamOnYUKBxcHJRlf0tyXsgJ /u+zR8zmkryr8P8U2igM8iyt+wFAf+apniB2QJAMXNGEZ07v4EIZb2OgGpTbLWzcXdBMEwnY 3gyPA8gH4RLL/dU/tcll2sNacb8CBeecphgy/HAFjLbM2G3/eGwrbpuyo0Gu7ZEgtwXaazaK oYH3bYpTY92NVTobkKKG6KAzxU5eLek7MOSuVd6PAxiPLAVcyQIDAQABozAwLjAeBgNVHREE FzAVgRNwaGlsLmhhcm1hbkBzdW4uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQAD gYEAsthm7K1edgeby8ThOb6QgZSkFIMJk8dFjxqqYNMytZsafq/Uw77Aqht+JUPoffWLpub2 4ix9BbU5CIQMNt+iUrmTPmcP5qMJsLLnWrL3AfZ9iLWxQjzaDzVFbd1g/Yluq79Q9NsaCKmn YjzsUKyBb8U+S3rUzCbT0HTFr5/JhOcwggLTMIICPKADAgECAgML3UAwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MDMwODEwMzYyNFoXDTA1MDMwODEwMzYyNFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWls IE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTcGhpbC5oYXJtYW5Ac3VuLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAO4DTqE9uB3C30aOlW3G1u6ZKNXfGBFuhMnSZohUqvbV zyX15rAVGAuiMkdbc6N9n6IPDv13MNn6wNq2stmDZeE73VUdD50WkjoX+wXB5Qgvr4xxxDcD hYjtHnZLHrz2pjp2FCgcXByUZX9Lcl7ICf7vs0fM5pK8q/D/FNooDPIsrfsBQH/mqZ4gdkCQ DFzRhGdO7+BCGW9joBqU2y1s3F3QTBMJ2N4MjwPIB+ESy/3VP7XJZdrDWnG/AgXnnKYYMvxw BYy2zNht/3hsK26bsqNBru2RILcF2ms2iqGB922KU2PdjVU6G5CihuigM8VOXi3pOzDkrlXe jwMYjywFXMkCAwEAAaMwMC4wHgYDVR0RBBcwFYETcGhpbC5oYXJtYW5Ac3VuLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALLYZuytXnYHm8vE4Tm+kIGUpBSDCZPHRY8a qmDTMrWbGn6v1MO+wKobfiVD6H31i6bm9uIsfQW1OQiEDDbfolK5kz5nD+ajCbCy51qy9wH2 fYi1sUI82g81RW3dYP2Jbqu/UPTbGgipp2I87FCsgW/FPkt61Mwm09B0xa+fyYTnMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/ DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODE3MTIxMDQyWjAjBgkqhkiG 9w0BCQQxFgQU3BaPKvRtQjFAc0M+wIY6yw8HeCwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwvdQDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwDQYJKoZIhvcNAQEBBQAEggEA JU0zuckZJAOIb7UMZfib3X4sWZHLQ8bFPK4ao6wfmj8Az6kkqHrSjHLcUdGm9XrqTtwLgHF6 AmqUai4Ob/FTvJmMeFb2KAUOL37UwGksrS+oUsmThDfolg/UZzFF97vc8/ggjb1jgz1HFmBa wcvEUbj8xz0cgXJhv/LovOf3YOL5aJOyeYN6pRWY/paQLP1pVHGyqfywyZvFVuphUnpYK/Te DiEVwLTW8JiWxWHzzsg/Ag+NB+9MqLLtzaNzdOsI8v7AGa6IPURpq7bRkBxgpxarC4fcTuq/ Iugh3TBuAL7YCZ/y4fwj7EiO2nw3W3r9Jz62uUJXNbX9DZDJIYxb8QAAAAAAAA== --------------ms020803040303080808050904-- From sacadmin Tue Aug 17 05:31:08 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Aug 2004 08:30:47 -0400 From: James Carlson To: Phil Harman Cc: psarc@sac.sfbay.sun.com, Frank.Dimambro@Sun.COM Subject: Re: 2004/614 Kernel-Level Atomic Operations Status: O Content-Length: 2992 Lines: 71 Phil Harman writes: > >I don't think the implementation is actually architecturally > >interesting. > > > > > > Indeed not. I was just quoting chapter and verse to underline that if we > need it, why do we think our ISVs don't? I don't doubt at all that our ISVs do need it. I just don't think it's a part of the case that's actually under review -- unless you can convince the submitter to design and implement the extensions you're asking about. > >The interesting point is that there isn't such a function defined in > >kernel or user space today, so this case doesn't cover it. It sounds > >like a good RFE that someone should file, evaluate properly, and > >implement. > > > > > > I'd just hoped for a bit more "yes we can do that too while we're at > it". Do we have a business case for each and every API in atomic_ops(3c)? Probably not, but I also don't think that what you're requesting is reasonably a part of this case. The original case was to (A) document and raise the stability level of the kernel bits that already exist [i.e., no code change] and (B) copy the code that already exists and is tested for the handful of operations that are in the kernel but weren't included in 2000/505 [i.e., minimal coding]. I don't see how designing and coding new functions that aren't already part of the implementation should be made part of this case. (But you're not complaining about the lack of a cas16 ... ?) > >Part of the point of the case was to avoid having the kernel and user > >space functions for these primitives diverge in name. I would *not* > >want to have, for example, atomic_cas_32() in user space and cas32() > >in the kernel. That seems gratuitous to me. > > > > > > But I would expect that from a kernel engineer :) Do we really want ISVs > to care about the vestigual organs of the kernel? I note that we already > diverge on many other APIs (e.g. thread_create / thr_create, mutex_enter > / mutex_lock, etc.) so what't the big deal? atomic_ops(3c) is something > completely new in S10 for ISVs. Why screw it up from the start? I still don't see how cas32() is "screwed up," but "atomic_cas_32" isn't. The existing atomic_ops(3C) functions that are prefixed with atomic_* form a special group. They're not conditional operations. I'd agree with you if you said that atomic_{set,clear}_long_excl were strange, and perhaps ought not be atomic_*. I'd also (less strongly) agree if you were suggesting putting the cas* functions on a different man page. Another compromise might be to drop part (B) of the case, and thus provide nothing new for user space programs beyond the existing atomic operations, and leave it for someone else to sort out. (Too bad, though, that AIX has a 10+ year jump on us here ...) -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Aug 17 05:52:57 2004 Date: Tue, 17 Aug 2004 13:52:26 +0100 From: Phil Harman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: psarc@sac.sfbay.sun.com, Frank.Dimambro@sun.com Subject: Re: 2004/614 Kernel-Level Atomic Operations Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000701010409070404020702" Status: O Content-Length: 8501 Lines: 185 This is a cryptographically signed message in MIME format. --------------ms000701010409070404020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit James Carlson wrote: >Phil Harman writes: > > >>>I don't think the implementation is actually architecturally >>>interesting. >>> >>> >>> >>> >>Indeed not. I was just quoting chapter and verse to underline that if we >>need it, why do we think our ISVs don't? >> >> > >I don't doubt at all that our ISVs do need it. I just don't think >it's a part of the case that's actually under review -- unless you can >convince the submitter to design and implement the extensions you're >asking about. > > Thanks, I think I may try this route. >>>The interesting point is that there isn't such a function defined in >>>kernel or user space today, so this case doesn't cover it. It sounds >>>like a good RFE that someone should file, evaluate properly, and >>>implement. >>> >>> >>> >>> >>I'd just hoped for a bit more "yes we can do that too while we're at >>it". Do we have a business case for each and every API in atomic_ops(3c)? >> >> > >Probably not, but I also don't think that what you're requesting is >reasonably a part of this case. > >The original case was to (A) document and raise the stability level of >the kernel bits that already exist [i.e., no code change] and (B) copy >the code that already exists and is tested for the handful of >operations that are in the kernel but weren't included in 2000/505 >[i.e., minimal coding]. > >I don't see how designing and coding new functions that aren't already >part of the implementation should be made part of this case. > >(But you're not complaining about the lack of a cas16 ... ?) > > OK, I think I now know where you are coming from. >>>Part of the point of the case was to avoid having the kernel and user >>>space functions for these primitives diverge in name. I would *not* >>>want to have, for example, atomic_cas_32() in user space and cas32() >>>in the kernel. That seems gratuitous to me. >>> >>> >>> >>> >>But I would expect that from a kernel engineer :) Do we really want ISVs >>to care about the vestigual organs of the kernel? I note that we already >>diverge on many other APIs (e.g. thread_create / thr_create, mutex_enter >>/ mutex_lock, etc.) so what't the big deal? atomic_ops(3c) is something >>completely new in S10 for ISVs. Why screw it up from the start? >> >> > >I still don't see how cas32() is "screwed up," but "atomic_cas_32" >isn't. > > Maybe it's just that I don't believe it belongs in a manpage called atomic_ops(3c)? Maybe is would have been better as atomics(3c)? But it may also be that cas32() would be a better match (in terms of naming convention) with aadd32()? But since cas32() is the new kid on the block w.r.t. atomic_ops(3c), I think it is the one which should be made to conform. >The existing atomic_ops(3C) functions that are prefixed with atomic_* >form a special group. They're not conditional operations. > > Yeah, but right now they are the only ones in the atomic_ops(3c) manpage. >I'd agree with you if you said that atomic_{set,clear}_long_excl were >strange, and perhaps ought not be atomic_*. I'd also (less strongly) >agree if you were suggesting putting the cas* functions on a different >man page. > > Maybe that's why I thought the cas* cases stood out so much! >Another compromise might be to drop part (B) of the case, and thus >provide nothing new for user space programs beyond the existing atomic >operations, and leave it for someone else to sort out. (Too bad, >though, that AIX has a 10+ year jump on us here ...) > > Yes, I might just step up to that :) I would certainly like to see more along the lines of stbar(), and perhaps tighten up the atomic_ops(3c) store semantics generally (i.e. make it explicit). Phil --------------ms000701010409070404020702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8TCC AtMwggI8oAMCAQICAwvdQDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzA4MTAzNjI0WhcNMDUwMzA4MTAzNjI0 WjBFMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNw aGlsLmhhcm1hbkBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7gNO oT24HcLfRo6VbcbW7pko1d8YEW6EydJmiFSq9tXPJfXmsBUYC6IyR1tzo32fog8O/Xcw2frA 2ray2YNl4TvdVR0PnRaSOhf7BcHlCC+vjHHENwOFiO0edksevPamOnYUKBxcHJRlf0tyXsgJ /u+zR8zmkryr8P8U2igM8iyt+wFAf+apniB2QJAMXNGEZ07v4EIZb2OgGpTbLWzcXdBMEwnY 3gyPA8gH4RLL/dU/tcll2sNacb8CBeecphgy/HAFjLbM2G3/eGwrbpuyo0Gu7ZEgtwXaazaK oYH3bYpTY92NVTobkKKG6KAzxU5eLek7MOSuVd6PAxiPLAVcyQIDAQABozAwLjAeBgNVHREE FzAVgRNwaGlsLmhhcm1hbkBzdW4uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQAD gYEAsthm7K1edgeby8ThOb6QgZSkFIMJk8dFjxqqYNMytZsafq/Uw77Aqht+JUPoffWLpub2 4ix9BbU5CIQMNt+iUrmTPmcP5qMJsLLnWrL3AfZ9iLWxQjzaDzVFbd1g/Yluq79Q9NsaCKmn YjzsUKyBb8U+S3rUzCbT0HTFr5/JhOcwggLTMIICPKADAgECAgML3UAwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MDMwODEwMzYyNFoXDTA1MDMwODEwMzYyNFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWls IE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTcGhpbC5oYXJtYW5Ac3VuLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAO4DTqE9uB3C30aOlW3G1u6ZKNXfGBFuhMnSZohUqvbV zyX15rAVGAuiMkdbc6N9n6IPDv13MNn6wNq2stmDZeE73VUdD50WkjoX+wXB5Qgvr4xxxDcD hYjtHnZLHrz2pjp2FCgcXByUZX9Lcl7ICf7vs0fM5pK8q/D/FNooDPIsrfsBQH/mqZ4gdkCQ DFzRhGdO7+BCGW9joBqU2y1s3F3QTBMJ2N4MjwPIB+ESy/3VP7XJZdrDWnG/AgXnnKYYMvxw BYy2zNht/3hsK26bsqNBru2RILcF2ms2iqGB922KU2PdjVU6G5CihuigM8VOXi3pOzDkrlXe jwMYjywFXMkCAwEAAaMwMC4wHgYDVR0RBBcwFYETcGhpbC5oYXJtYW5Ac3VuLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALLYZuytXnYHm8vE4Tm+kIGUpBSDCZPHRY8a qmDTMrWbGn6v1MO+wKobfiVD6H31i6bm9uIsfQW1OQiEDDbfolK5kz5nD+ajCbCy51qy9wH2 fYi1sUI82g81RW3dYP2Jbqu/UPTbGgipp2I87FCsgW/FPkt61Mwm09B0xa+fyYTnMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/ DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODE3MTI1MjI2WjAjBgkqhkiG 9w0BCQQxFgQUKu1tgBlGTPmHlPKDCzWckqJ16GwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwvdQDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML3UAwDQYJKoZIhvcNAQEBBQAEggEA kp/8s3yRMlm0sFTAglbbb/Gi74rnETQnO9dNe03rxR2plLwWnxbUvw1k56Drb61Dr4/BLHjd UBIbtAxhHaYaDc6/l7gEXgmpMejMN5mrXAAa/DGpBeVlYQzMC6+NMNGXG6TZB3PdYPNnBkMQ ZS2Zvp6k4E6icamAquCHbSKRCUk15W67pOcBSGenDglKSQCecDFe4YtS3DzvcXVzxUAEIpzb 7x+Jnjs2nSYYY8wb8sAu0QW+zftzXXjcYrJboeXgYnbCmA8fZ+x//J2yezQi3mPkMon0TObo u3wn3mi7SizEpUKFQoDuid+xCXyWruDazw3k2p8nnRM5XOIrp1D0hwAAAAAAAA== --------------ms000701010409070404020702-- From sacadmin Tue Aug 17 11:34:25 2004 Date: Tue, 17 Aug 2004 08:37:45 -1000 (HST) From: "Joseph E. Kowalski III" Subject: Re: 2004/614 Kernel-Level Atomic Operations To: james.d.carlson@sun.com, phil.harman@sun.com Cc: psarc@sac.sfbay.sun.com, Frank.Dimambro@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KypdCkb9+IfVcn3lQR7BTQ== Status: O Content-Length: 939 Lines: 20 > I'd just hoped for a bit more "yes we can do that too while we're at > it". Do we have a business case for each and every API in atomic_ops(3c)? The project team can do that if it wants, but this case is not incomplete without it (IMHO), so its not appropriate for PSARC to dictate extra work. Certainly I don't think PSARC would object. > But I would expect that from a kernel engineer :) Do we really want ISVs > to care about the vestigual organs of the kernel? I note that we already > diverge on many other APIs (e.g. thread_create / thr_create, mutex_enter > / mutex_lock, etc.) so what't the big deal? atomic_ops(3c) is something > completely new in S10 for ISVs. Why screw it up from the start? I think the concern is the other way around. Although only a select, elite, gifted few 8^) play in the kernel, *everybody* plays in userland. There is no reason to further confuse those elite who play both places. - jek3 From sacadmin Thu Aug 19 11:14:36 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Aug 2004 14:14:13 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: frank.dimambro@Sun.COM Subject: 2004/614 Kernel-Level Atomic Operations Status: RO Content-Length: 393 Lines: 8 This fast-track request was approved during ARC business at yesterday's meeting. A final version of the specification (unchanged) is in the case directory as spec.txt. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Sun Apr 10 21:28:10 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j3B4SASp013264 for ; Sun, 10 Apr 2005 21:28:10 -0700 (PDT) Received: from jurassic (jurassic [129.146.17.57]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j3B4QNRM473573; Sun, 10 Apr 2005 21:26:23 -0700 (PDT) Message-Id: <200504110426.j3B4QNRM473573@jurassic.eng.sun.com> Date: Sun, 10 Apr 2005 21:26:23 -0700 (PDT) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: 2004/614 Kernel-Level Atomic Operations To: psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DqyriT+NonrXJeblU0CyCQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_47 SunOS 5.10 sun4u sparc Status: RO Content-Length: 1000 This case: 2004/614 Kernel-Level Atomic Operations was approved as a fast-track in the Solaris 10 time frame: Name: Kernel-Level Atomic Operations Submitter: Frank Dimambro Owner: James Carlson Interest: Status: closed approved fast-track 08/18/2004 but the change did not get into Solaris 10. I integrated it into Solaris Nevada under bugid: 4954703 userland atomic.h port should include cas primitives Now I want to patch it back to Solaris 10. However, I need clarification about the original PSARC approval. James had originally requested "Minor" release binding: The requested release binding is "Minor". but this was not mentioned anywhere else in the mail trail. Since I want to patch it back to Solaris 10, the PSARC decision should specify the release binding. So I'm requesting that the case be revisited for the purpose of specifying the release binding to be "Micro" (or "Patch" if that is the proper terminology). Thanks, Roger Faulkner From sacadmin Sun Apr 10 21:50:49 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j3B4omSp013350 for ; Sun, 10 Apr 2005 21:50:49 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j3B4mxOp010501; Mon, 11 Apr 2005 00:48:59 -0400 (EDT) Subject: Re: 2004/614 Kernel-Level Atomic Operations From: Bill Sommerfeld To: "Roger A. Faulkner" Cc: psarc@sac.sfbay.sun.com In-Reply-To: <200504110426.j3B4QNRM473573@jurassic.eng.sun.com> References: <200504110426.j3B4QNRM473573@jurassic.eng.sun.com> Content-Type: text/plain Message-Id: <1113194916.18060.526.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 11 Apr 2005 00:48:37 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 373 On Mon, 2005-04-11 at 00:26, Roger A. Faulkner wrote: > So I'm requesting that the case be revisited for the purpose > of specifying the release binding to be "Micro" (or "Patch" if > that is the proper terminology). "Micro" would be for 5.10.1 "Patch" would be for S10 update N for any value of N. but in any event this looks fine to me as a patch release candidate. From sacadmin Sun Apr 10 22:28:56 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j3B5SuSp015882 for ; Sun, 10 Apr 2005 22:28:56 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.86.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j3B5R8kH029847; Sun, 10 Apr 2005 22:27:08 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j3B5PhDX008081; Sun, 10 Apr 2005 22:25:43 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j3B5PgiM008080; Sun, 10 Apr 2005 22:25:42 -0700 (PDT) Date: Sun, 10 Apr 2005 22:25:42 -0700 (PDT) From: Gary Winiger Message-Id: <200504110525.j3B5PgiM008080@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com, Roger.Faulkner@eng.sun.com Subject: Re: 2004/614 Kernel-Level Atomic Operations X-Sun-Charset: US-ASCII Status: RO Content-Length: 496 > I integrated it into Solaris Nevada under bugid: > James had originally requested "Minor" release binding: > The requested release binding is "Minor". Syntax error. Nevada is a Micro release. Don't tell the gatekeepers or it ``should'' be backed out. > of specifying the release binding to be "Micro" (or "Patch" if > that is the proper terminology). Looking at the case materials, I don't see why it wouldn't qualify for a Micro (Nevada) or a Patch (S10uX) release. Gary..