Frank Batschulat (Home)
2009-10-17 13:55:31 UTC
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 ?
yes, there is, PSARC/2009/566this, 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 ?
http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-October/018617.html
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
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