sync with the recent reality. (allocbuf; hi, pk)

This commit is contained in:
yamt 2004-06-17 13:13:41 +00:00
parent d08f636e0f
commit f34604727e
1 changed files with 10 additions and 6 deletions

View File

@ -1,4 +1,4 @@
.\" $NetBSD: buffercache.9,v 1.11 2003/11/04 13:45:52 keihan Exp $
.\" $NetBSD: buffercache.9,v 1.12 2004/06/17 13:13:41 yamt Exp $
.\"
.\" Copyright (c)2003 YAMAMOTO Takashi,
.\" All rights reserved.
@ -101,7 +101,7 @@
.\"
.\"
.\" ------------------------------------------------------------
.Dd September 15, 2003
.Dd June 17, 2004
.Dt BUFFERCACHE 9
.Os
.Sh NAME
@ -148,7 +148,7 @@
.Ft struct buf *
.Fn incore "struct vnode *vp" "daddr_t blkno"
.Ft void
.Fn allocbuf "struct buf *bp" "int size"
.Fn allocbuf "struct buf *bp" "int size" "int preserve"
.Ft void
.Fn brelse "struct buf *bp"
.Ft void
@ -290,10 +290,14 @@ Note that
doesn't busy the buffer unlike
.Fn getblk .
.\" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
.It Fn allocbuf "bp" "size"
.It Fn allocbuf "bp" "size" "preserve"
Expand or contract the actual memory allocated to a buffer.
If the buffer shrinks, data is lost, so it's up to the caller to have written
it out *first*; this routine will not start a write.
If
.Fa preserve
is zero, entire data in the buffer will be lost.
Otherwise, if the buffer shrinks, truncated part of data is lost,
so it's up to the caller to have written
it out *first* if needed; this routine will not start a write.
If the buffer grows, it's the callers responsibility to fill out
the buffer's additional contents.
.\" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -