NetBSD Problem Report #44208

From yamt@NetBSD.org  Wed Dec  8 22:49:44 2010
Return-Path: <yamt@NetBSD.org>
Received: by www.NetBSD.org (Postfix, from userid 1270)
	id C41B463B87A; Wed,  8 Dec 2010 22:49:44 +0000 (UTC)
Message-Id: <20101208224944.C41B463B87A@www.NetBSD.org>
Date: Wed,  8 Dec 2010 22:49:44 +0000 (UTC)
From: yamt@NetBSD.org
Reply-To: yamt@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: puffs_ops(3) doesn't document advlock
X-Send-Pr-Version: 3.95

>Number:         44208
>Category:       lib
>Synopsis:       puffs_ops(3) doesn't document advlock
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 08 22:50:00 +0000 2010
>Last-Modified:  Mon Dec 13 09:10:08 +0000 2010
>Originator:     YAMAMOTO Takashi
>Release:        NetBSD-current
>Organization:

>Environment:
>Description:
	pufs_ops(3) doesn't say anything about some callbacks,
	including puffs_node_advlock.
>How-To-Repeat:

>Fix:


>Audit-Trail:
From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/44208
Date: Fri, 10 Dec 2010 16:39:43 +0200

 That's because puffs_advlock is broken ;)

 See kern/43321

 I guess an easy way to "fix" it is to just make it call lf_advlock()
 in the kernel.  That would at least fix running vi to not give a warning
 when run on puffs file systems.

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	yamt@NetBSD.org
Subject: Re: kern/44208
Date: Mon, 13 Dec 2010 00:14:34 +0000 (UTC)

 hi,

 >  That's because puffs_advlock is broken ;)
 >  
 >  See kern/43321

 i didn't notice it.  thanks.
 how about abortop?

 >  I guess an easy way to "fix" it is to just make it call lf_advlock()
 >  in the kernel.  That would at least fix running vi to not give a warning
 >  when run on puffs file systems.

 is there anything which prevents a file system from implementing
 an lf_advlock equivalent (or a more complicated one like NLM) by their own?

 YAMAMOTO Takashi

From: "Antti Kantee" <pooka@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44208 CVS commit: src/lib/libpuffs
Date: Mon, 13 Dec 2010 09:06:52 +0000

 Module Name:	src
 Committed By:	pooka
 Date:		Mon Dec 13 09:06:52 UTC 2010

 Modified Files:
 	src/lib/libpuffs: puffs_ops.3

 Log Message:
 document abortop.  part of PR kern/44208


 To generate a diff of this commit:
 cvs rdiff -u -r1.26 -r1.27 src/lib/libpuffs/puffs_ops.3

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Antti Kantee <pooka@cs.hut.fi>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, yamt@NetBSD.org
Subject: Re: kern/44208
Date: Mon, 13 Dec 2010 11:07:58 +0200

 On Mon Dec 13 2010 at 00:14:34 +0000, YAMAMOTO Takashi wrote:
 > hi,
 > 
 > >  That's because puffs_advlock is broken ;)
 > >  
 > >  See kern/43321
 > 
 > i didn't notice it.  thanks.
 > how about abortop?

 Well, abortop is kind of an afterthought to be able to run kernel file
 servers from libp2k.  For "normal" file servers componentname is always
 what is passed down from the kernel, so there is no automatic state in
 lookup in userspace.  I guess I could fix protocol so that componentname
 would be cached in libpuffs, but that's not a high priority, and that
 code is supposed to be changing in weird and wonderous ways anyway.

 I added some explanation on the manpage.

 > >  I guess an easy way to "fix" it is to just make it call lf_advlock()
 > >  in the kernel.  That would at least fix running vi to not give a warning
 > >  when run on puffs file systems.
 > 
 > is there anything which prevents a file system from implementing
 > an lf_advlock equivalent (or a more complicated one like NLM) by their own?

 I'm under the recollection that it's not possible for some fundamental
 reason, but I might misremember.  In any case, the kernel vop should
 stop trying to copyin struct flock for anything to even remotely work ;)

 -- 
 älä karot toivorikkauttas, kyl rätei ja lumpui piisaa

>Unformatted:

Home	PR Database Search