kill bhv_vnode_t

Dave complained today that the fate of bhv_vnode_t isn't entirely clear yet, so I've prepared these two patches to kill it in a minimally invasive way. While it causes churn in a lot of areas it does not affect the generated code at all.

Quoted 6 lines · Christoph Hellwig

Dave complained today that the fate of bhv_vnode_t isn't entirely clear yet, so I've prepared these two patches to kill it in a minimally invasive way. While it causes churn in a lot of areas it does not affect the generated code at all.

I know a bunch of stuff has gone in that is not very portable, which is fine since
they can be dealt with individually since they are not that intrusive.

Changing bhv_vnode_t to struct inode throughout the code is a pretty big change and would be a major pain to work around.

Quoted 9 lines · Russell Cattelan

Quoted 7 lines · Christoph Hellwig

Dave complained today that the fate of bhv_vnode_t isn't entirely clear yet, so I've prepared these two patches to kill it in a minimally invasive way. While it causes churn in a lot of areas it does not affect the generated code at all.

Quoted 6 lines

I know a bunch of stuff has gone in that is not very portable, which is fine since they can be dealt with individually since they are not that intrusive.

Changing bhv_vnode_t to struct inode throughout the code is a pretty big change and would be a major pain to work around.

Have you actually looed at the patches? The only places where we use struct inode outside of linux-2.6/ are:

- xfs_finish_reclaim:

Distangles the xfs_inode from Linux inode. Per defintion OS-specific.

- xfs_sync_inodes:

Sync code that is quite OS specific. Dave will move it to linux-2.6/ pretty soon.

- quota/xfs_qm_syscalls.c:

Similar sync code.

- xfs_acl.c:

ACL code with some OS dependencies, and pretty dead with my pending patch to use the generic ACL code.

And no, it's not actually a big change.