Re: Re: FreeBSD 5-current client work....

--On Thursday, September 25, 2003 13:39:20 -0400 Garrett Wollman
<[email protected]> wrote:

> The concern about the funky allocators in afs_osi_alloc.c is that it's
> generally a bad idea for a subsystem to maintain its own freelists,
> since that is memory that, once allocated, can never be reclaimed for
> another purpose.  I'm guessing that in traditional (4BSD)
> implementations, ``small'' allocations were done in mbufs, ``medium''
> allocations used mbuf clusters, and ``large'' used I/O buffers,
> correct?

This does not appear to be the case (having just checked the afs 3.2
source). It seems that all allocations eventually resulted in calls to
malloc, kmem_alloc, or new_kmem_alloc (in the case of sunos 4). It's my
belief that the freelists maintained by afs were intended to reduce
fragmentation. 

Yes, modern systems with zone allocators don't have that problem, but I
don't think that customizing afs to each new operating system's way of
doing things is really the right thing to do (except, as in the case of the
vnode/vcache thing, where the old way causes real problems). But that's
just my opinion.

Onto another thing. Is there a good technical reason for this:?
@@ -60,8 +60,10 @@
 	vfs_register(&afs_vfsconf);	/* doesn't fail */
 	vfs_add_vnodeops(&afs_vnodeop_opv_desc);
 	osi_Init();
+#ifdef DO_NOT_EVER_EVER_DO_THIS
 	sysent[SYS_setgroups].sy_call = Afs_xsetgroups;
 	sysent[SYS_ioctl].sy_call = afs_xioctl;
+#endif

I can understand disabling ioctl. I no longer remember what application it
was that used ioctl as a gateway into pioctl, and it's unlikely that
anything still does that, but without the setgroups intercept, PAGs are not
durable, and you're stuck with uid-bound tokens. Is that really what the
freebsd users want?