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

[Dale Ghent]

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.

Are these changes happening under a specific PSARC that's in the open  
on arc.o.o ?

/dale

On Oct 9, 2009, at 12:32 PM, Frank Batschulat (Home) wrote:

> 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.
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel