DragonFly kernel List (threaded) for 2008-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: sys/buf.h struct buf missing b_blkno member
:Thank you very much for the explanation :-)
:
:I am editing sbin/vinum/list.c (VINUMDEBUG defined) and there I have
:replaced rq.info.b.b_blkno for rq.info.bio.bio_offset. rq is a struct
:rqinfo (from sys/dev/raid/vinum/request.h):
: struct bio *bio; /* point to
:user buffer */
: union {
: struct buf b; /* yup, the
:*whole* buffer header */
: struct bio bio;
:...
:
:But I have seen in list.c references to rq.info.rqe.b.b_blkno:
:b is known to be a struct buf, but since b_blkno is wiped out from
:there, how is it supposed to calculate this? I have tried replacing it
:rq.info.rqe.b.b_bio1.bio_offset and it compiles, but I'm almost sure
:that's not the correct layer for that context.
:
:There's no bio defined on struct rqelement
:(sys/dev/raid/vinum/request.h). Is this supposed to be that way?
:
:I'm kinda lost here.
:
:Thanks
:Antonio Huete
One of the reasons why vinum is such a mess is that it synthesizes
buffer cache buffers all over the place, Ultimately though, somewhere
in that mess, there is the original BIO that the I/O was initiated
from.
For the BUF/BIO's that the buffer cache synthesizes you have full
control over which BIO in the BUF is being used, so in fact for the
synthesized BUFs you can use (buf->b_bio{1/2}) to access underlying
offsets, as long as the same access point is used consistently
throughout vinum.
You can't calculate the block number from a buffer passed into vinum
because there is no way to know which BIO is the right one. It
can only be calculated from a BIO... specifically, the BIO
passed into vinum. BIOs are passed in from higher layers, not BUFs,
so vinum is probably getting the buf from bio->bio_buf in that case.
The BIO needs to be retained.
-Matt
Matthew Dillon
<dillon@backplane.com>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]