Tracy Di Marco White <[EMAIL PROTECTED]> writes: > I've been looking at making OpenAFS work on NetBSD/amd64. I have no > problems with NetBSD/i386, with and without PAM (well, other than I have > to use arla for actual client support), but on amd64 with PAM I'm seeing > the need for the same type of hackery. What would be the direction > needed to go for making this work in the mainline source tree?
Well, there are a couple of problems with integrating this into mainline: * Linking with all the object files of the shared libraries except for some excluded with grep -v is just too ugly for words. It's a minimal change for Debian, which is why I did it that way (the entirety of the change is localized in pam/Makefile.in), but it's not the right way to do it in mainline. The best thing to do, of course, would be to link the PAM modules against the actual shared libraries, but this requires finalizing (or at least commiting to stabilizing) the ABI of the shared libraries and making sure that they're handled properly on at least the major platforms we care about. * Right now, using the pthread libraries will mean that the PAM modules, if run with nofork (and the current forking mode is an ugly hack), will leak threads. That should be fixed. Maybe there's some way to get the PAM module to kill the thread off when it's done authenticating, some way that isn't too high on overhead? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
