Subject: Re: curproc removal (NFS, ...)
To: None <tech-kern@NetBSD.org>
From: David Young <dyoung@pobox.com>
List: tech-kern
Date: 05/24/2004 12:40:12
On Mon, May 24, 2004 at 07:00:26PM +0200, Matthias Drochner wrote:
>
> Hi -
> I'm getting tons of kernel warnings now on a -current diskless box:
> nfs_send: proc botch: rep 0x0 arg 0x0 curproc 0xc71dc1d0
> nfs_send: proc botch: rep 0x0 arg 0x0 curproc 0xc71dc008
> nfs_send: proc botch: rep 0x0 arg 0x0 curproc 0xc7e068f4
> [...]
>
> Looking at the reason I've found 3 NFS calls for now which pass
> a 0 proc* down:
> -the asynchronous readahead (nfssvc_iod)
> -the sillyrename stuff (nfs_removeit)
> -readlink
>
> This appears easily fixed, but it is not obvious what the
> proc pointer is used for in every case. This might be:
> -scheduling (ultimatively to be passed to ltsleep())
> -access rights
> -accounting
> -address space for virtual addresses
A programmer here in Urbana has convinced me that passing "blobs" of
state like struct proc is a Bad Idea precisely because it makes the
code hard to read and re-factor later. In this instance, if the three
NFS calls had passed only the scheduling, access rights, accounting,
or address space parts of the proc, then the function of the calls would
be much more clear.
(BTW, passing around softc in drivers is a bad practice that I intend
to break myself of.)
Dave
--
David Young OJC Technologies
dyoung@ojctech.com Urbana, IL * (217) 278-3933