Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Nov 2002 18:31:09 -0500
From:      Hiten Pandya <hiten@angelica.unixdaemons.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        Nate Lawson <nate@root.org>, current@FreeBSD.ORG
Subject:   Re: Searching for users of netncp and nwfs to help debug 5.0 problems
Message-ID:  <20021126233109.GA37462@angelica.unixdaemons.com>
In-Reply-To: <Pine.BSF.4.21.0211261305510.52749-100000@InterJet.elischer.org>
References:  <Pine.BSF.4.21.0211261254100.86771-100000@root.org> <Pine.BSF.4.21.0211261305510.52749-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 26, 2002 at 01:10:45PM -0800, Julian Elischer wrote the words in effect of:
> 
> 
> On Tue, 26 Nov 2002, Nate Lawson wrote:
> 
> > On Tue, 26 Nov 2002, Hiten Pandya wrote:
> > > On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of:
> > > > In file included from /home/src/sys/netncp/ncp_conn.c:46:
> > > > /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type
> > > > /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out
> > > > *** Error code 1
> > > > 
> > > > I guess struct lock can't be found.
> > > > 
> > > > I hope someone can do something with this.
> > > > 
> > > 
> > > Once you change the <sys/lock.h> line in ncp_conn.h to <sys/lockmgr.h>, you
> > > will see a lot of struct proc related errors springing up.  The motto of this
> > > message is, that fixing that line will not make it compile.
> > > 
> > > We need to make sys/netncp use struct thread instead of struct proc.
> > > This is easy in some parts of the code, and on some its just a little
> > > tricky, but not hard.  Somebody did update the prototypes to netncp, but
> > > forgot to change the logic, for lockmgr calls, example, its last
> > > argument is a struct thread etc.
> > > 
> > > I was going to work on this task at one point in time, but now that my
> > > school exam timetable has changed, I will not be able to do it; for the
> > > next 2/3 months anyway.
> > > 
> > > If someone wants to give a go at this task, then they are most welcome
> > > to take my place.
> > 
> > I thought Julian volunteered to do this a while back.  If he is not, I can
> > pick this up and make it compile but I have no equipment to test it on.
> 
> It's not so much that I volunteered as I said that I'd help with
> thread/proc issues..
> The trouble was that there are places where it used a proc in the old
> code, but in some cases it needs to be a proc, and in other cases it now
> needs to be a thread. But all they stored was the proc. Also, from
> my memories of the code you needed to understand the protocol to know
> which needed to be which, and I don't know that protocol.
> 
> In addition whoever does it needs to remember that any structure that
> stores a thread poitner is probably in error, as threads
> are transient items and any stored thread pointer is probably a wild
> pointer within a few milliseconds of being stored. :-)

Changes in ncp_conn.[ch] do not require a lot of netncp-foo.  But other
modules like ncp_ncp.[ch] might do.  Julian's KSE Milestone 2 commit
_did_ touch ncp_conn.h and ncp_rq.h.

FWIW, some of the code in netncp does not even need a struct proc, but
its just there, for some reason.  If no one picks this task up, I will
eventually get back to it, but not in the next 3/4 weeks or so.

Cheers.

-- 
Hiten Pandya (hiten@unixdaemons.com, hiten@uk.FreeBSD.org)
http://www.unixdaemons.com/~hiten/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021126233109.GA37462>