I'm currently trying to get the client working under FreeBSD 5-current. I've tried to improve some of the significant synchronization issues in the existing code, which is looking like the hardest part of the project. (I haven't looked at any of the VM integration issues yet -- I've confirmed that pioctl(), fstat(), and getdirentries() work in /afs, but that's about it.) If I can stop holding my nose at the stink of some of this code for a little bit, these were the issues I have run into so far:
- Lots of potential for ISO C aliasing bugs; I've hacked around this with -fno-strict-alias for now. - It is essential that libafs.ko be compiled using the kernel's actual option headers (opt_global.h in particular) and not fake ones. Perhaps once this is debugged there will be less of a need for this. FBSD/vfs_vnops.h in particular is bad juju. I just modified MakefileProto.FBSD.in to hack in the right cc options. (There have been a few times when I've hand-hacked config.status, too, to remove bogus compiler options that I just haven't gotten around to figuring out the configure tests for). - Most of the necessary fixes were simply telling the FreeBSD port to use the same serup as OpenBSD. It will never be possible (or sensible) for AFS to ``subclass'' struct vnode in FreeBSD. - afs_xioctl() is utterly broken. Thankfully it's also entirely unnecessary. I just removed it. - AFS needs to implement VOP_PATHCONF() or else everyday utilities like ls(1) get really unhappy. (I don't know why ls needs pathconf(), nor do I care to find out. It Just Needs To Work.) - The shutdown code is called with init's proc lock held, and at some point it tries to sleep, which is not permitted (you can't sleep while a mutex other than Giant is held). - I've tried to reimplement most of osi_sleep.c, which was quite nasty-looking. In order to do that, while avoiding race conditions, I turned afs_global_lock into afs_global_mtx. This brought up the most serious problem I've come up against: the AFS code loves to call OSI_KALLOC() with the global lock held. It also loves to call other kernel entry points like namei() in similar situations. I need to have it not do that; how badly is the code likely to break if I drop the global lock in these places? (As noted in the last paragraph, you can't sleep while a mutex other than Giant is held. In addition, the WITNESS lock debugging tool noted a lock order reversal [possible deadlock] which dropping afs_global_mtx will probably resolve as a side effect.) - It seems as if, with a decent kernel memory allocator, almost all of afs_osi_alloc() could be thrown out. Thoughts on doing this? This would be similar to what I've done in FBSD/osi_sleep.c (in terms of replacing bad emulations of kernel primitives -- condition variables in that case -- with the real thing), and I suspect it would make debugging much easier. A slightly stale version of the diffs I've got now can be found at <http://lcs.mit.edu/~wollman/openafs-fbsd52.patch>. -GAWollman _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
