> On 2. Feb 2018, at 09:55, Stephan Wiesand <stephan.wies...@desy.de> wrote: > > >> On 2. Feb 2018, at 02:14, Benjamin Kaduk <ka...@mit.edu> wrote: >> >> On Thu, Feb 01, 2018 at 05:11:24PM +0100, Stephan Wiesand wrote: >>> Comparing the 1.6.22.2 module builds from the SL packaging, where the kABI >>> hashes of the used symbols are stored as a requirement, is seems none of >>> those hashes changed between -693 and -830. >>> >>> There are two differences in the configure results: >>> >>> -ac_cv_linux_header_sched_signal_h=no >>> +ac_cv_linux_header_sched_signal_h=yes >>> >>> -ac_cv_linux_struct_file_operations_has_iterate=no >>> +ac_cv_linux_struct_file_operations_has_iterate=yes >> >> That's very helpful to know. >> >> Does the new tree actually have a sched/signal.h header? > > Yes it does. The only content is a guarded include of <linux/sched.h> > >> Does the new struct file_operations have an 'iterate' member >> function? > > Yes it does, wrapped in a RH_KABI_ITERATE macro.
er, nonsense, that's RH_KABI_EXTEND, sorry > >> (The idea being to tell whether they changed something in new and >> interesting ways or our configure test(s) are broken.) > > It's the former :-( _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
