[OpenAFS-devel] Q: pending Solaris changes that can potentially affect OpenAFS on Solaris

[Chas Williams (CONTRACTOR)]

In message <723C7F03-3807-413A-B1D3-4B8A67AFA148@elemental.org>,Dale Ghent writ
es:
>Thanks for the heads-up, Frank. Given the lack of reply since you sent  
>this, I don't think anything immediately knows off thei top of their  
>head, and I don't either. Investigation is in order.

as i recall, afs creates a static array of 'struct vnode' and then
proceeds to use them.  but...

>> The changes are two-fold: an addition to the 'vfs_impl_t' and
>> a change to the behaviour of vfs_add()/vfs_list_add().
>>
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/
>vfs.c
>>
>> In the latter case, we will be forcibly allocating a 'vfs_impl_t' to  
>> any
>> 'vfs_t' that has a NULL 'vfs_t->vfs_implp'.
>>
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys
>/vfs.h
>>
>> Well-behaved file systems are passed by the generic kernel code  
>> ( vfs.c:domount() )
>> a 'vfs_t' which they might modify in some way. Such file systems
>> will be unaffected.

if i understand this correctly, this shouldnt affect afs.  afs doesnt
use one of its own vnode's when inserting the root mount point.
however, if you call vget() for the filesystem (afs in this case)
being mounted then yes we might have a problem but it doesnt appear
that way to me though glancing through solaris' vfs.c

>> However we've seen file systems that might "allocate" their own  
>> 'vfs_t'
>> and then insert it into the global list, probably through an existing
>> "interface" such as vfs_add() or vfs_list_add(). (NB. which is a bad  
>> thing(TM))

afs doesnt use these.