From sacadmin Mon Nov 19 20:19:08 2007 Received: from sunraf.sfbay.sun.com (sunraf [129.146.177.11]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAK4J8mP023563; Mon, 19 Nov 2007 20:19:08 -0800 (PST) Received: from sunraf.sfbay.sun.com (localhost [127.0.0.1]) by sunraf.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lAK4ITil127181; Mon, 19 Nov 2007 20:18:30 -0800 (PST) Received: (from raf@localhost) by sunraf.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id lAK4ITo4127177; Mon, 19 Nov 2007 20:18:29 -0800 (PST) Date: Mon, 19 Nov 2007 20:18:29 -0800 (PST) From: "Roger A. Faulkner" Message-Id: <200711200418.lAK4ITo4127177@sunraf.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: delete sched_nice [PSARC/2007/661 FastTrack timeout 11/30/2007] Status: RO Content-Length: 560 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: delete sched_nice 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 19 November, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/NET 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Mon Nov 19 20:25:33 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAK4PXTJ023628 for ; Mon, 19 Nov 2007 20:25:33 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with SMTP id lAK4PWFC263826; Mon, 19 Nov 2007 20:25:32 -0800 (PST) Message-Id: <200711200425.lAK4PWFC263826@jurassic-x4600.sfbay.sun.com> Date: Mon, 19 Nov 2007 20:25:32 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: PSARC/2007/661 - delete sched_nice To: psarc@sac.sfbay.sun.com Cc: john.zolnowsky@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y5o5tboBoP5SBh5y9M5Hmw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_74 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2721 I am sponsoring this fast-track case for myself. This proposal will time out 11/30/2007. The proposal in this case is to delete the sched_nicelim and sched_nice members of 'struct sched_param'. See bugid: 4468577 Define or Remove sched_nicelim and sched_nice from sched_param struct These fields were introduced into 'struct sched_param' in 1993, as part of the POSIX scheduling project. They are not specified by POSIX. They appear in no Solaris man pages. The only mention of them in any Sun document is in the specification file, 930908.spec.ps, in the PSARC case: PSARC 1993/295 P1003.4 Compliance - Phase II but no description of them exists in that PSARC case. The only mention of them when searching in Google is in a Solaris to HP-UX porting guide: http://devrsrc1.external.hp.com/STKS/impacts/i232.html which says: Problem description The sched_param data structure defined in sched.h on Solaris systems contains two more fields than the sched_param data structure (also defined in sched.h) on HP-UX systems. The two fields are: int sched_nicelim; /* nice value limit for SCHED_OTHER policy */ int sched_nice; /* nice value for SCHED_OTHER policy */ Solution description Review your code and make the applicable changes to resolve this issue. You will need to remove any occurrences of sched_nicelim and sched_nice before recompiling your code. If your application relies on the values of sched_nicelim and sched_nice, you will need to compute them using the nice() function. Refer to the manpage for more information. John Zolnowsky gives some history in the Evaluation of 4468577: The sched_nicelim and sched_nice members were indeed introduced into the sched_param structure as a Solaris-specific extension. The motivation was to provide full access to the functionality provided for the TS class under priocntl. However, this exension was never fully designed or implemented, and those members were left around as a result of this incomplete work. Since the introduction of the priocntl(2) PC_DONICE interface: PSARC/2000/247 Priority Control Enhancements provides a much better and class-independent method for dealing with the nice condition of processes and threads, and since the two abandoned members of 'struct sched_param', sched_nicelim and sched_nice, cannot be used in any meaningful way (they yield incorrect nice values for SCHED_OTHER processes), they should be deleted (keeping the size of 'struct sched_param' unchanged). The proposed release binding for this case is "patch release" so it can be back-ported as a patch to SunOS 5.10 if desirable. Roger Faulkner From Roger.Faulkner@sun.com Tue Nov 20 11:07:15 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAKJ7FCC008105 for ; Tue, 20 Nov 2007 11:07:15 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with SMTP id lAKJ7F9i494926; Tue, 20 Nov 2007 11:07:15 -0800 (PST) Message-Id: <200711201907.lAKJ7F9i494926@jurassic-x4600.sfbay.sun.com> Date: Tue, 20 Nov 2007 11:07:15 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: PSARC/2007/661 - delete sched_nice To: psarc-ext@sac.sfbay.sun.com Cc: john.zolnowsky@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y5o5tboBoP5SBh5y9M5Hmw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_74 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2721 I am sponsoring this fast-track case for myself. This proposal will time out 11/30/2007. The proposal in this case is to delete the sched_nicelim and sched_nice members of 'struct sched_param'. See bugid: 4468577 Define or Remove sched_nicelim and sched_nice from sched_param struct These fields were introduced into 'struct sched_param' in 1993, as part of the POSIX scheduling project. They are not specified by POSIX. They appear in no Solaris man pages. The only mention of them in any Sun document is in the specification file, 930908.spec.ps, in the PSARC case: PSARC 1993/295 P1003.4 Compliance - Phase II but no description of them exists in that PSARC case. The only mention of them when searching in Google is in a Solaris to HP-UX porting guide: http://devrsrc1.external.hp.com/STKS/impacts/i232.html which says: Problem description The sched_param data structure defined in sched.h on Solaris systems contains two more fields than the sched_param data structure (also defined in sched.h) on HP-UX systems. The two fields are: int sched_nicelim; /* nice value limit for SCHED_OTHER policy */ int sched_nice; /* nice value for SCHED_OTHER policy */ Solution description Review your code and make the applicable changes to resolve this issue. You will need to remove any occurrences of sched_nicelim and sched_nice before recompiling your code. If your application relies on the values of sched_nicelim and sched_nice, you will need to compute them using the nice() function. Refer to the manpage for more information. John Zolnowsky gives some history in the Evaluation of 4468577: The sched_nicelim and sched_nice members were indeed introduced into the sched_param structure as a Solaris-specific extension. The motivation was to provide full access to the functionality provided for the TS class under priocntl. However, this exension was never fully designed or implemented, and those members were left around as a result of this incomplete work. Since the introduction of the priocntl(2) PC_DONICE interface: PSARC/2000/247 Priority Control Enhancements provides a much better and class-independent method for dealing with the nice condition of processes and threads, and since the two abandoned members of 'struct sched_param', sched_nicelim and sched_nice, cannot be used in any meaningful way (they yield incorrect nice values for SCHED_OTHER processes), they should be deleted (keeping the size of 'struct sched_param' unchanged). The proposed release binding for this case is "patch release" so it can be back-ported as a patch to SunOS 5.10 if desirable. Roger Faulkner From sacadmin Wed Nov 21 01:39:06 2007 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAL9d6ed028107 for ; Wed, 21 Nov 2007 01:39:06 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAL9d5cG008693 for ; Wed, 21 Nov 2007 01:39:06 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAL9d0Ak005782 for ; Wed, 21 Nov 2007 09:39:00 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JRU00D01O2KJY00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 21 Nov 2007 17:39:00 +0800 (SGT) Received: from [129.158.12.60] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JRU00HF4O4XYN9E@mail-apac.sun.com>; Wed, 21 Nov 2007 17:38:59 +0800 (SGT) Date: Wed, 21 Nov 2007 20:38:56 +1100 From: Alan Hargreaves Subject: Re: PSARC/2007/661 - delete sched_nice In-reply-to: <200711200425.lAK4PWFC263826@jurassic-x4600.sfbay.sun.com> Sender: Alan.Hargreaves@Sun.COM To: "Roger A. Faulkner" Cc: psarc@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM Message-id: <4743FCB0.8010109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200711200425.lAK4PWFC263826@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 4134 Roger, just to be clear, are you looking at removing them (and making the structure smaller) or simply increasing the size of the pad array so as to keep the size of the struct consistent with what is discussed in the comments: struct sched_param { int sched_priority; /* process execution scheduling priority */ int sched_nicelim; /* nice value limit for SCHED_OTHER policy */ int sched_nice; /* nice value for SCHED_OTHER policy */ int sched_pad[6]; /* pad to the same size as pcparms_t of */ /* sys/priocntl.h */ /* sizeof(sched_priority) + */ /* sizeof(pcparms_t.pc_clparms) */ }; I suspect the latter, but I think that it should be mentioned in the mail archive for clarity. I was going to say I'd be concerned if the structure size was changing, but a quick search of ON don't turn up anything actually including this type in the middle of a structure, so even if it is the case, I'm ok with a patch binding. Regards, Alan Hargreaves Roger A. Faulkner wrote: > I am sponsoring this fast-track case for myself. > This proposal will time out 11/30/2007. > > The proposal in this case is to delete the sched_nicelim and sched_nice > members of 'struct sched_param'. See bugid: > > 4468577 Define or Remove sched_nicelim and sched_nice from sched_param struct > > These fields were introduced into 'struct sched_param' in 1993, as part > of the POSIX scheduling project. They are not specified by POSIX. > They appear in no Solaris man pages. The only mention of them in any > Sun document is in the specification file, 930908.spec.ps, in the PSARC case: > PSARC 1993/295 P1003.4 Compliance - Phase II > but no description of them exists in that PSARC case. > > The only mention of them when searching in Google is in a > Solaris to HP-UX porting guide: > http://devrsrc1.external.hp.com/STKS/impacts/i232.html > which says: > > Problem description > > The sched_param data structure defined in sched.h on Solaris > systems contains two more fields than the sched_param data > structure (also defined in sched.h) on HP-UX systems. > The two fields are: > > int sched_nicelim; /* nice value limit for SCHED_OTHER policy */ > int sched_nice; /* nice value for SCHED_OTHER policy */ > > Solution description > > Review your code and make the applicable changes to resolve this > issue. You will need to remove any occurrences of sched_nicelim > and sched_nice before recompiling your code. > > If your application relies on the values of sched_nicelim and > sched_nice, you will need to compute them using the nice() > function. Refer to the manpage for more information. > > John Zolnowsky gives some history in the Evaluation of 4468577: > > The sched_nicelim and sched_nice members were indeed introduced > into the sched_param structure as a Solaris-specific extension. > > The motivation was to provide full access to the functionality > provided for the TS class under priocntl. However, this exension > was never fully designed or implemented, and those members were > left around as a result of this incomplete work. > > Since the introduction of the priocntl(2) PC_DONICE interface: > PSARC/2000/247 Priority Control Enhancements > provides a much better and class-independent method for > dealing with the nice condition of processes and threads, > and since the two abandoned members of 'struct sched_param', > sched_nicelim and sched_nice, cannot be used in any meaningful > way (they yield incorrect nice values for SCHED_OTHER processes), > they should be deleted (keeping the size of 'struct sched_param' > unchanged). > > The proposed release binding for this case is "patch release" > so it can be back-ported as a patch to SunOS 5.10 if desirable. > > Roger Faulkner > > -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Support Centre Sun Microsystems From Roger.Faulkner@Sun.COM Wed Nov 21 03:23:03 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lALBN3Q0029643 for ; Wed, 21 Nov 2007 03:23:03 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with SMTP id lALBMP16679104; Wed, 21 Nov 2007 03:23:02 -0800 (PST) Message-Id: <200711211123.lALBMP16679104@jurassic-x4600.sfbay.sun.com> Date: Wed, 21 Nov 2007 03:23:02 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2007/661 - delete sched_nice To: Alan.Hargreaves@Sun.COM Cc: psarc-ext@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 06Av2uQBUBZ4kwqwuhmr2g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_74 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2162 > Date: Wed, 21 Nov 2007 20:38:56 +1100 > From: Alan Hargreaves > Subject: Re: PSARC/2007/661 - delete sched_nice > To: "Roger A. Faulkner" > Cc: psarc@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM > > Roger, just to be clear, are you looking at removing them (and making > the structure smaller) or simply increasing the size of the pad array so > as to keep the size of the struct consistent with what is discussed in > the comments: > > struct sched_param { > int sched_priority; /* process execution scheduling priority */ > int sched_nicelim; /* nice value limit for SCHED_OTHER > policy */ > int sched_nice; /* nice value for SCHED_OTHER policy */ > int sched_pad[6]; /* pad to the same size as pcparms_t of */ > /* sys/priocntl.h */ > /* sizeof(sched_priority) + */ > /* sizeof(pcparms_t.pc_clparms) */ > }; > > I suspect the latter, but I think that it should be mentioned in the > mail archive for clarity. I did mention this, at the end of the next-to-last paragraph of my original mail, not too obviously since it was parenthetical: Since the introduction of the priocntl(2) PC_DONICE interface: PSARC/2000/247 Priority Control Enhancements provides a much better and class-independent method for dealing with the nice condition of processes and threads, and since the two abandoned members of 'struct sched_param', sched_nicelim and sched_nice, cannot be used in any meaningful way (they yield incorrect nice values for SCHED_OTHER processes), they should be deleted (keeping the size of 'struct sched_param' unchanged). So yes, sched_pad[6] would become sched_pad[8]. Roger > I was going to say I'd be concerned if the structure size was changing, > but a quick search of ON don't turn up anything actually including this > type in the middle of a structure, so even if it is the case, I'm ok > with a patch binding. > > Regards, > Alan Hargreaves From Alan.Hargreaves@Sun.COM Wed Nov 21 04:37:13 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lALCbDjU000238 for ; Wed, 21 Nov 2007 04:37:13 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lALCbB1k001643 for ; Wed, 21 Nov 2007 04:37:12 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lALCb6pU014125 for ; Wed, 21 Nov 2007 12:37:06 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JRU00301W6B2U00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 21 Nov 2007 20:37:06 +0800 (SGT) Received: from [192.168.10.101] ([60.240.40.166]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JRU00HWLWDPYE04@mail-apac.sun.com>; Wed, 21 Nov 2007 20:37:06 +0800 (SGT) Date: Wed, 21 Nov 2007 23:35:20 +1100 From: Alan Hargreaves Subject: Re: PSARC/2007/661 - delete sched_nice In-reply-to: <200711211123.lALBMP16679104@jurassic-x4600.sfbay.sun.com> Sender: Alan.Hargreaves@Sun.COM To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM Message-id: <47442608.8050803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200711211123.lALBMP16679104@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 2437 Roger A. Faulkner wrote: >> Date: Wed, 21 Nov 2007 20:38:56 +1100 >> From: Alan Hargreaves >> Subject: Re: PSARC/2007/661 - delete sched_nice >> To: "Roger A. Faulkner" >> Cc: psarc@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM >> >> Roger, just to be clear, are you looking at removing them (and making >> the structure smaller) or simply increasing the size of the pad array so >> as to keep the size of the struct consistent with what is discussed in >> the comments: >> >> struct sched_param { >> int sched_priority; /* process execution scheduling priority */ >> int sched_nicelim; /* nice value limit for SCHED_OTHER >> policy */ >> int sched_nice; /* nice value for SCHED_OTHER policy */ >> int sched_pad[6]; /* pad to the same size as pcparms_t of */ >> /* sys/priocntl.h */ >> /* sizeof(sched_priority) + */ >> /* sizeof(pcparms_t.pc_clparms) */ >> }; >> >> I suspect the latter, but I think that it should be mentioned in the >> mail archive for clarity. >> > > I did mention this, at the end of the next-to-last paragraph of my > original mail, not too obviously since it was parenthetical: > > Since the introduction of the priocntl(2) PC_DONICE interface: > PSARC/2000/247 Priority Control Enhancements > provides a much better and class-independent method for > dealing with the nice condition of processes and threads, > and since the two abandoned members of 'struct sched_param', > sched_nicelim and sched_nice, cannot be used in any meaningful > way (they yield incorrect nice values for SCHED_OTHER processes), > they should be deleted (keeping the size of 'struct sched_param' > unchanged). > > So yes, sched_pad[6] would become sched_pad[8]. > > Roger > > >> I was going to say I'd be concerned if the structure size was changing, >> but a quick search of ON don't turn up anything actually including this >> type in the middle of a structure, so even if it is the case, I'm ok >> with a patch binding. >> >> Regards, >> Alan Hargreaves >> > > Thanks Roger. alan. -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Service Center Sun Microsystems From sacadmin Mon Nov 26 18:40:18 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAR2eID4025142 for ; Mon, 26 Nov 2007 18:40:18 -0800 (PST) Received: from [129.150.12.137] (vpn-129-150-12-137.SFBay.Sun.COM [129.150.12.137]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lAR2eHfB795650; Mon, 26 Nov 2007 18:40:17 -0800 (PST) Message-ID: <474B8372.2080306@sun.com> Date: Mon, 26 Nov 2007 16:39:46 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: Alan Hargreaves CC: "Roger A. Faulkner" , psarc@sac.sfbay.sun.com, John.Zolnowsky@sun.com, Darrin.Johnson@sun.com Subject: Re: PSARC/2007/661 - delete sched_nice References: <200711200425.lAK4PWFC263826@jurassic-x4600.sfbay.sun.com> <4743FCB0.8010109@Sun.COM> In-Reply-To: <4743FCB0.8010109@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 737 Alan Hargreaves wrote: > I was going to say I'd be concerned if the structure size was > changing, but a quick search of ON don't turn up anything actually > including this type in the middle of a structure, so even if it is the > case, I'm ok with a patch binding. I'm kinda wondering what the motivation is for this project. It seems like a nice bit of clean-up but I can't see any other motivation. This leaves me unmotivated for anything other than a Minor binding. This is where and when we do clean-up. There was a day where the mantra for Updates was "don't change anything you don't have to". I'd hope that mantra is somewhat still intact. I know, there probably isn't any "architecture" in this mantra.... - jek3 From sacadmin Tue Nov 27 07:11:55 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lARFBtrO013373 for ; Tue, 27 Nov 2007 07:11:55 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with SMTP id lARFBnE1997418; Tue, 27 Nov 2007 07:11:55 -0800 (PST) Message-Id: <200711271511.lARFBnE1997418@jurassic-x4600.sfbay.sun.com> Date: Tue, 27 Nov 2007 07:11:55 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2007/661 - delete sched_nice To: Alan.Hargreaves@sun.com, jek3@sun.com Cc: psarc@sac.sfbay.sun.com, John.Zolnowsky@sun.com, Darrin.Johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YoTgTe62n6XC6aMY2EsZPQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_74 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1853 > Date: Mon, 26 Nov 2007 16:39:46 -1000 > From: Joseph Kowalski > Subject: Re: PSARC/2007/661 - delete sched_nice > To: Alan Hargreaves > Cc: "Roger A. Faulkner" , psarc@sac.sfbay.sun.com, John.Zolnowsky@sun.com, Darrin.Johnson@sun.com > > Alan Hargreaves wrote: > > I was going to say I'd be concerned if the structure size was > > changing, but a quick search of ON don't turn up anything actually > > including this type in the middle of a structure, so even if it is the > > case, I'm ok with a patch binding. > I'm kinda wondering what the motivation is for this project. It seems > like a nice bit of clean-up but I can't see any other motivation. > > This leaves me unmotivated for anything other than a Minor binding. > This is where and when we do clean-up. There was a day where the mantra > for Updates was "don't change anything you don't have to". I'd hope > that mantra is somewhat still intact. > > I know, there probably isn't any "architecture" in this mantra.... > > - jek3 Actually, this fix is one small piece of a much larger project I am working on: Fixing the various priority control interfaces to be consistent with one other: pthread_setschedparam() pthread_getschedparam() pthread_setschedprio() pthread_mutexattr_setprioceiling() pthread_mutexattr_getprioceiling() pthread_attr_setschedpolicy() pthread_attr_getschedpolicy() pthread_attr_setschedparam() pthread_attr_getschedparam() thr_setprio() thr_getprio() priocntl() sched_getparam(); sched_setparam(); sched_getscheduler(); sched_setscheduler(); sched_get_priority_max(); sched_get_priority_min(); sched_rr_get_interval(); I have no intention of back-porting this wad to S10, but somebody might come out of the woodwork and request it. That's why I asked for patch binding. Roger From sacadmin Tue Nov 27 12:08:41 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lARK8frt020301 for ; Tue, 27 Nov 2007 12:08:41 -0800 (PST) Received: from [129.150.12.137] (vpn-129-150-12-137.SFBay.Sun.COM [129.150.12.137]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lARK8dX5150118; Tue, 27 Nov 2007 12:08:40 -0800 (PST) Message-ID: <474C7928.9070001@sun.com> Date: Tue, 27 Nov 2007 10:08:08 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: "Roger A. Faulkner" CC: Alan.Hargreaves@sun.com, psarc@sac.sfbay.sun.com, John.Zolnowsky@sun.com, Darrin.Johnson@sun.com Subject: Re: PSARC/2007/661 - delete sched_nice References: <200711271511.lARFBnE1997418@jurassic-x4600.sfbay.sun.com> In-Reply-To: <200711271511.lARFBnE1997418@jurassic-x4600.sfbay.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2006 Roger A. Faulkner wrote: >> Date: Mon, 26 Nov 2007 16:39:46 -1000 >> From: Joseph Kowalski >> Subject: Re: PSARC/2007/661 - delete sched_nice >> To: Alan Hargreaves >> Cc: "Roger A. Faulkner" , psarc@sac.sfbay.sun.com, >> > John.Zolnowsky@sun.com, Darrin.Johnson@sun.com > >> Alan Hargreaves wrote: >> >>> I was going to say I'd be concerned if the structure size was >>> changing, but a quick search of ON don't turn up anything actually >>> including this type in the middle of a structure, so even if it is the >>> case, I'm ok with a patch binding. >>> >> I'm kinda wondering what the motivation is for this project. It seems >> like a nice bit of clean-up but I can't see any other motivation. >> >> This leaves me unmotivated for anything other than a Minor binding. >> This is where and when we do clean-up. There was a day where the mantra >> for Updates was "don't change anything you don't have to". I'd hope >> that mantra is somewhat still intact. >> >> I know, there probably isn't any "architecture" in this mantra.... >> >> - jek3 >> > > Actually, this fix is one small piece of a much larger project > I am working on: Fixing the various priority control interfaces > to be consistent with one other: > > pthread_setschedparam() > pthread_getschedparam() > pthread_setschedprio() > pthread_mutexattr_setprioceiling() > pthread_mutexattr_getprioceiling() > pthread_attr_setschedpolicy() > pthread_attr_getschedpolicy() > pthread_attr_setschedparam() > pthread_attr_getschedparam() > thr_setprio() > thr_getprio() > priocntl() > sched_getparam(); > sched_setparam(); > sched_getscheduler(); > sched_setscheduler(); > sched_get_priority_max(); > sched_get_priority_min(); > sched_rr_get_interval(); > > I have no intention of back-porting this wad to S10, but somebody > might come out of the woodwork and request it. That's why I asked > for patch binding. > > Roger > > ACK! - jek3 From sacadmin Tue Dec 4 06:55:20 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4EtKsj027338 for ; Tue, 4 Dec 2007 06:55:20 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with SMTP id lB4EtJxp132352; Tue, 4 Dec 2007 06:55:20 -0800 (PST) Message-Id: <200712041455.lB4EtJxp132352@jurassic-x4600.sfbay.sun.com> Date: Tue, 4 Dec 2007 06:55:20 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2007/661 - delete sched_nice To: jek3@Sun.COM Cc: psarc@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: x5HeYoyH7ArpX94LHENhaA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1946 > Date: Tue, 27 Nov 2007 10:08:08 -1000 > From: Joseph Kowalski > Subject: Re: PSARC/2007/661 - delete sched_nice > To: "Roger A. Faulkner" > Cc: Alan.Hargreaves@Sun.COM, psarc@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM > > >> I'm kinda wondering what the motivation is for this project. It seems > >> like a nice bit of clean-up but I can't see any other motivation. > >> > >> This leaves me unmotivated for anything other than a Minor binding. > >> This is where and when we do clean-up. There was a day where the mantra > >> for Updates was "don't change anything you don't have to". I'd hope > >> that mantra is somewhat still intact. > >> > >> I know, there probably isn't any "architecture" in this mantra.... > >> > >> - jek3 > > > > Actually, this fix is one small piece of a much larger project > > I am working on: Fixing the various priority control interfaces > > to be consistent with one other: > > > > pthread_setschedparam() > > pthread_getschedparam() > > pthread_setschedprio() > > pthread_mutexattr_setprioceiling() > > pthread_mutexattr_getprioceiling() > > pthread_attr_setschedpolicy() > > pthread_attr_getschedpolicy() > > pthread_attr_setschedparam() > > pthread_attr_getschedparam() > > thr_setprio() > > thr_getprio() > > priocntl() > > sched_getparam(); > > sched_setparam(); > > sched_getscheduler(); > > sched_setscheduler(); > > sched_get_priority_max(); > > sched_get_priority_min(); > > sched_rr_get_interval(); > > > > I have no intention of back-porting this wad to S10, but somebody > > might come out of the woodwork and request it. That's why I asked > > for patch binding. > > > > Roger > > > ACK! > > - jek3 Since no one objected and the timer ran out, I marked this case as 'closed approved' in the IAM.delete_sched_nice file. I just want to be clear: Is 'patch binding' OK or should it be 'minor binding'? Thanks, Roger From sacadmin Tue Dec 4 07:01:47 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4F1lql027436 for ; Tue, 4 Dec 2007 07:01:47 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lB4F0oBe010337; Tue, 4 Dec 2007 10:00:50 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lB4F0o19010334; Tue, 4 Dec 2007 10:00:50 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18261.27554.270529.154939@gargle.gargle.HOWL> Date: Tue, 4 Dec 2007 10:00:50 -0500 From: James Carlson To: "Roger A. Faulkner" Cc: jek3@Sun.COM, psarc@sac.sfbay.sun.com, John.Zolnowsky@Sun.COM, Darrin.Johnson@Sun.COM Subject: Re: PSARC/2007/661 - delete sched_nice In-Reply-To: <200712041455.lB4EtJxp132352@jurassic-x4600.sfbay.sun.com> References: <200712041455.lB4EtJxp132352@jurassic-x4600.sfbay.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 619 Roger A. Faulkner writes: > Since no one objected and the timer ran out, I marked this > case as 'closed approved' in the IAM.delete_sched_nice file. > > I just want to be clear: > Is 'patch binding' OK or should it be 'minor binding'? We approved the case (as originally specified, with patch binding) during ARC business on 11/28/2007. See: /shared/sac/PSARC/Minutes/2007/20071128.arcbiz -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Dec 4 11:10:40 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4JAegC007393 for ; Tue, 4 Dec 2007 11:10:40 -0800 (PST) Received: from [129.150.12.243] (vpn-129-150-12-243.SFBay.Sun.COM [129.150.12.243]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lB4JAdbJ175946; Tue, 4 Dec 2007 11:10:39 -0800 (PST) Message-ID: <4755A607.50107@sun.com> Date: Tue, 04 Dec 2007 09:09:59 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: "Roger A. Faulkner" CC: psarc@sac.sfbay.sun.com, John.Zolnowsky@sun.com, Darrin.Johnson@sun.com Subject: Re: PSARC/2007/661 - delete sched_nice References: <200712041455.lB4EtJxp132352@jurassic-x4600.sfbay.sun.com> In-Reply-To: <200712041455.lB4EtJxp132352@jurassic-x4600.sfbay.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 572 Roger A. Faulkner wrote: >>> >>> I have no intention of back-porting this wad to S10, but somebody >>> might come out of the woodwork and request it. That's why I asked >>> for patch binding. >>> >>> Roger >>> >>> >> ACK! >> >> - jek3 >> > > Since no one objected and the timer ran out, I marked this > case as 'closed approved' in the IAM.delete_sched_nice file. > > I just want to be clear: > Is 'patch binding' OK or should it be 'minor binding'? > > Thanks, > Roger > As Jim said, patch binding was fine. Sorry if my "ACK" was too terse. - jek3