G_BIO (9) | Kernel routines | Unix Manual Pages

G_BIO (9) | Kernel routines | Unix Manual Pages | :man▋

`BIO_READ`	A read request.
`BIO_WRITE`	A write request.
`BIO_DELETE`	Indicates that a certain range of data is no longer used and that it can be erased or freed as the underlying technology supports. Technologies like flash adaptation layers can arrange to erase the relevant blocks before they will become reassigned and cryptographic devices may want to fill random bits into the range to reduce the amount of data available for attack.
`BIO_GETATTR`	Inspect and manipulate out-of-band attributes on a particular provider or path. Attributes are named by ascii strings and are stored in the bio_attribute field.

bio_flags

Available flags:

`BIO_ERROR`	Request failed (error value is stored in bio_error field).
`BIO_DONE`	Request finished.

bio_cflags	Private use by the consumer.
bio_pflags	Private use by the provider.
bio_offset	Offset into provider.
bio_data	Pointer to data buffer.
bio_error	Error value when `BIO_ERROR` is set.
bio_done	Pointer to function which will be called when the request is finished.
bio_driver1	Private use by the provider.
bio_driver2	Private use by the provider.
bio_caller1	Private use by the consumer.
bio_caller2	Private use by the consumer.
bio_attribute
	Attribute string for `BIO_GETATTR` request.
bio_from	Consumer to use for request (attached to provider stored in bio_to field) (typically read-only for a class).
bio_to	Destination provider (typically read-only for a class).
bio_length	Request length in bytes.
bio_completed
	Number of bytes completed, but they may not be completed from the front of the request.
bio_children	Number of .Vt bio clones (typically read-only for a class).
bio_inbed	Number of finished .Vt bio clones.
bio_parent	Pointer to parent .Vt bio .

The g_new_bio function allocates a new, empty
.Vt bio structure.

The g_clone_bio function allocates a new
.Vt bio structure and copies the following fields from the
.Vt bio given as an argument to clone: bio_cmd, bio_length, bio_offset, bio_data, bio_attribute. The field bio_parent in the clone points to the passed
.Vt bio and the field bio_children in the passed
.Vt bio is incremented.

This function should be used for every request which enters through the provider of a particular geom and needs to be scheduled down. Proper order is:

Clone the received
.Vt "struct bio" .
Modify the clone.
Schedule the clone on its own consumer.

The g_destroy_bio function deallocates and destroys the given
.Vt bio structure.

The g_print_bio function prints information about the given
.Vt bio structure (for debugging purposes).

RETURN VALUES

The g_new_bio and g_clone_bio functions return a pointer to the allocated
.Vt bio , or NULL if an error occurred.

EXAMPLES

Implementation of "NULL -transformation", meaning that an I/O request is cloned and scheduled down without any modifications. Let us assume that field ex_consumer in structure
.Vt example_softc contains a consumer attached to the provider we want to operate on.
void
example_start(struct bio *bp)
{
struct example_softc *sc;
struct bio *cbp;

printf("Request received: ");
g_print_bio();
printf("\n");

sc = bp->bio_to->geom->softc;
if (sc == NULL) {
g_io_deliver(bp, ENXIO);
return;
}

/* Let’s clone our bio request. */
cbp = g_clone_bio(bp);
if (cbp == NULL) {
g_io_deliver(bp, ENOMEM);
return;
}
cbp->bio_done = g_std_done;/* Standard ’done’ function. */

/* Ok, schedule it down. */
/*
* The consumer can be obtained from
* LIST_FIRST(&bp->bio_to->geom->consumers) as well,
* if there is only one in our geom.
*/
g_io_request(cbp, sc->ex_consumer);
}

AUTHORS

greatis just4fun network

NAME

CONTENTS

SYNOPSIS

DESCRIPTION

RETURN VALUES

EXAMPLES

SEE ALSO

AUTHORS