lockmgr and VFS plans

Hi,
as previously explained in past e-mails, lockmgr() is going
to face a
massive restructuration.
The work is progressing on two different rails: the former
involves
fixing consumers code in order to make it completely
implementative
details agnostic, in order to make it cleaner and more
robust. The
latter involves giving a good replacement for current
functions and a
faster implementation.
lockmgr() is an old primitive widely used in our VFS
subsystem, so
this overhaul would involve someway VFS subsystem
necessarilly, in
particular about the former line of development.

Part of this overhaul (for this preliminary stages) consists
in
removing the 'thread' argument from the lockmgr() interface
which also
means making useless the same argument about VFS functions
(vn_lock,
VOP_LOCK() and VOP_UNLOCK()). This removal can be done in a
'stacked'
way and can be splitted in 2 different stages: the former
will clean
up only vn_lock() while the latter will be more aggressive
and it will
involve hardly VFS, fixing VOP_LOCK1() and VOP_UNLOCK().
This patch
removes the 'thread' argument from vn_lock():
http:
//people.freebsd.org/~attilio/vn_lock.diff

What I'm looking for is:
- objections to this
- testers (even if a small crowd alredy offered to test this
patch)

I test-compiled and runned LINT with this patch and it
works
perfectly, but a wider audience would be better.

I also would appreciate a lot if people planning to do
changes to
lockmgr or VFS would coordinate their efforts with me, even
on small
changes.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

On Wed, Jan 09, 2008 at 03:19:35PM +0100, Attilio Rao
wrote:
> Hi,
> as previously explained in past e-mails, lockmgr() is
going to face a
> massive restructuration.
> The work is progressing on two different rails: the
former involves
> fixing consumers code in order to make it completely
implementative
> details agnostic, in order to make it cleaner and more
robust. The
> latter involves giving a good replacement for current
functions and a
> faster implementation.
> lockmgr() is an old primitive widely used in our VFS
subsystem, so
> this overhaul would involve someway VFS subsystem
necessarilly, in
> particular about the former line of development.
> 
> Part of this overhaul (for this preliminary stages)
consists in
> removing the 'thread' argument from the lockmgr()
interface which also
> means making useless the same argument about VFS
functions (vn_lock,
> VOP_LOCK() and VOP_UNLOCK()). This removal can be done
in a 'stacked'
> way and can be splitted in 2 different stages: the
former will clean
> up only vn_lock() while the latter will be more
aggressive and it will
> involve hardly VFS, fixing VOP_LOCK1() and
VOP_UNLOCK(). This patch
> removes the 'thread' argument from vn_lock():
> http:
//people.freebsd.org/~attilio/vn_lock.diff
> 

I'll try and test it this wekend.

> What I'm looking for is:
> - objections to this
> - testers (even if a small crowd alredy offered to test
this patch)
> 
> I test-compiled and runned LINT with this patch and it
works
> perfectly, but a wider audience would be better.
> 
> I also would appreciate a lot if people planning to do
changes to
> lockmgr or VFS would coordinate their efforts with me,
even on small
> changes.
> 
> Thanks,
> Attilio
> 
> 
> -- 
> Peace can only be achieved by understanding - A.
Einstein
> _______________________________________________
> freebsd-archfreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch

> To unsubscribe, send any mail to
"freebsd-arch-unsubscribefreebsd.org"

-- 
Peter Holm
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"