sys/buf.h struct buf missing b_blkno member

Matthew Dillon dillon at apollo.backplane.com
Tue Jul 8 14:06:53 PDT 2008


: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 at backplane.com>





More information about the Kernel mailing list