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

[Frank Batschulat (Home)]

friends,

We're about to make some changes in the development release of
Solaris that will in due course be backported to Solaris 10 as well.

We're trying to ensure that we won't break any unbundled file
systems.
 
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.
 
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))

Such file systems might be a problem depending on how they initialise
'vfs_t->vfs_implp' and how they insert the 'vfs_t' into the global list
of vfs instances. 
 
I'm therefore keen to learn whether OpenAFS perhaps allocates its own
'vfs_t' and, if so, what it then does with it.

Can you please let us know if that may cause headaches on your end ?

thanks!
-- 
frankB

It is always possible to agglutinate multiple separate problems
into a single complex interdependent solution.
In most cases this is a bad idea.