Date: Sat, 21 Jun 1997 22:35:08 +1000 From: Bruce Evans <bde@zeta.org.au> To: jhay@mikom.csir.co.za, joerg_wunsch@uriah.heep.sax.de Cc: hackers@FreeBSD.ORG Subject: Re: Proposed change to struct clockinfo Message-ID: <199706211235.WAA28756@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > As far as I can tell only 4 other files use the clockinfo structure and >> > they will work again after a recompile. They are: >> > lib/libc/gmon/gmon.c >> > usr.bin/time/time.c >> > usr.sbin/kgmon/kgmon.c >> > libexec/rpc.rstatd/rstat_proc.c >> suffice (i assume, even though strictly spoken, isn't it an interface >> change to an existing library function? -- this would mandate a major >> number bump, sigh). >> > >The interface to the library function does not change. The sysctl change >and lib/libc/gmon/gmon.c use that, so it will have to be recompiled to >work again. So I think the minor version bump that already happened >should be enough??? The other programs in the list above use the sysctl >direcly and would also have to be recompiled, but I don't think that is >a problem??? Strictly, it requires even more than a major version number bump. It breaks all programs linked to the old gmon object. To avoid breaking them, you have to implement a new sysctl to return the new struct. It's just like the non-problem with stat(2) and the problem with fcntl(2). When the size and shape of `struct stat' changed, there had to be a new syscall to prevent breakage. When the size (and shape?) of `struct flock' changed, there should have been a new syscall to prevent breakage (there wasn't). Anyway, only the static version of the gmon object in the profiling library is normally used, so changing the version number of the shared library won't help. The profiling library seems to be rarely used, and gmon has reasonable fallback code, so it is probably OK not to implement a new sysctl in this case. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706211235.WAA28756>