[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#297769: patch



At Mon, 11 Apr 2005 12:35:29 -0400,
Daniel Jacobowitz wrote:
> 
> On Tue, Apr 12, 2005 at 01:30:08AM +0900, GOTO Masanori wrote:
> > OK, I put the patch.  Currently I found the problem about schedutils.
> > 
> > Once schedutils `taskset' command uses new sched_getaffinity and
> > sched_setaffinity interface (which has GLIBC_2.3.4), schedutils has to
> > depend on glibc >= 2.3.2.ds1-21.
> > I'm currently searching how to set Depends: libc6 (>= 2.3.2.ds1-21) or
> > libc6.1 (>= 2.3.2.ds1-21) [ia64, alpha] for schedutils.
> > 
> > BTW, if we change the library exported symbol version, GLIBC_2.3.4, we
> > should always bump up our shlibs from 2.3.2.ds1-4 to 2.3.2.ds1-21.
> > However, such change affects almost all binaries.  Is this acceptable?
> > IMHO, changing shlibs affects a lot of packages, so I would like to
> > take the workaround fix - schedutils and fakeroot just have special
> > Depends: >= 2.3.2.ds1-21, because I guess sched_{get,set}affinity is
> > not used widely.
> 
> I think that we should just be bumping the shlibdeps; the release team
> has already agreed that we need a glibc update for sarge.

I think it's not same issue; bumping shlib version is not glibc bug
fix update.

> In any case, the best way to do what you want in schedutils mightb be:
> Depends: ${shlib:Depends}

Back to the original suggestion by David Mosberger was: the recent
sources (ex: Lmbench3) use new sched_{set,get}affinity syscalls, so
such programs will need to consider debian's old syscalls interfaces
in future.

Thus, this change does _NOT_ affect any current debian archives.
These old syscalls are used by only fakeroot and schedutils, and the
current fakeroot/schedutils .debs do not use new syscalls.  When we
think only for debian, this change is not useful at all.  In other
words, this modification focuses on only unknown unbounded NON-DEBIAN
sources or binaries (even if old interfaces are incorrect).

I concern to bump up shlib version - I don't know why I'm worrying,
but at least when we discussed about this issue, we didn't anticipate
that adding new symbols makes additional consideration - I still think
bumping up shlib version needs incidental affection and it's large
change at this time.

> Conflicts: libc6 (<= 2.3.2.ds1-21), libc6.1 (<= 2.3.2.ds1-21)
> 
> I think that'll work... but make sure apt can cope.

We don't need any additional Conflicts because:

 (1) the current schedutils has Depends: libc6 (>= 2.3.2.ds1-4), and
     it works finely with libc6 2.3.2.ds1-21 because -21 also has old
     GLIBC_2.3.3 sched_{get,set}affinity symbols.

 (2) new schedutils has Depends: libc6 (>= 2.3.2.ds1-21) and
     Build-Depends: libc6 (>= 2.3.2.ds1-21).  It needs new libc6 -21,
     and it uses GLIBC_2.3.4 sched_{get,set}affinity.


So I would like to change as follows:

 (1) glibc -21 has new sched_{get,set}affinity at last.

 (2) New schedutils should be released until sarge release with the
     attached patch.

 (3) fakeroot does not need to be modified because it does not have
     any explicit sched_*affinity.  It seems schedutils is the only
     affected package.

I put new -21 and schedutils at:

	http://www.gotom.jp/~gotom/debian/glibc/2.3.2.ds1-21_i386.sched/

Steve, how about this thought?  Do you want to bump up glibc shlib
version rathar than my small hack?  I would like to hear your opinion
from the RM point of view.  Any comments are welcome.


--- schedutils-1.3.4/taskset.c.gotom	2005-04-12 00:13:07.000000000 +0900
+++ schedutils-1.3.4/taskset.c	2005-04-12 00:14:04.000000000 +0900
@@ -130,7 +130,7 @@
 	if (pid) {
 		unsigned long mask = 0;
 
-		if (sched_getaffinity(pid, &cur_mask) < 0) {
+		if (sched_getaffinity(pid, sizeof (cur_mask), &cur_mask) < 0) {
 			perror("sched_getaffinity");
 			fprintf(stderr, "failed to get pid %d's affinity\n",
 				pid);
@@ -152,13 +152,13 @@
 
 	ulong_to_cpu_set(the_mask, &new_mask);
 
-	if (sched_setaffinity(pid, &new_mask)) {
+	if (sched_setaffinity(pid, sizeof (new_mask), &new_mask)) {
 		perror("sched_setaffinity");
 		fprintf(stderr, "failed to set pid %d's affinity.\n", pid);
 		return 1;
 	}
 
-	if (sched_getaffinity(pid, &cur_mask) < 0) {
+	if (sched_getaffinity(pid, sizeof (cur_mask), &cur_mask) < 0) {
 		perror("sched_setaffinity");
 		fprintf(stderr, "failed to get pid %d's affinity.\n", pid);
 		return 1;
--- schedutils-1.3.4/debian/control.gotom	2005-04-11 15:33:36.000000000 +0000
+++ schedutils-1.3.4/debian/control	2005-04-11 23:54:06.000000000 +0000
@@ -2,12 +2,12 @@
 Section: utils
 Priority: optional
 Maintainer: Guus Sliepen <guus@debian.org>
-Build-Depends: debhelper (>> 3.0.0), libc6-dev (>= 2.3) [!ia64 !alpha], libc6.1-dev (>= 2.3) [ia64 alpha]
+Build-Depends: debhelper (>> 3.0.0), libc6-dev (>= 2.3.2.ds1-21) [!ia64 !alpha], libc6.1-dev (>= 2.3.2.ds1-21) [ia64 alpha]
 Standards-Version: 3.6.0
 
 Package: schedutils
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: libc6 (>= 2.3.2.ds1-21) | libc6.1 (>= 2.3.2.ds1-21)
 Description: Linux scheduler utilities
  These are the Linux scheduler utilities - schedutils for short. These programs
  take advantage of the scheduler family of syscalls that Linux implements across


Regards,
-- gotom



Reply to: