Source string Read only

(itstool) path: sect2/title
Context English State
In the case of creating/labeling a new geom, this is what happens:
<citerefentry><refentrytitle>geom</refentrytitle><manvolnum>8</manvolnum></citerefentry> looks in the command-line argument for the command (usually <option>label</option>), and calls a helper function.
The helper function checks parameters and gathers metadata, which it proceeds to write to all concerned providers.
This <quote>spoils</quote> existing geoms (if any) and initializes a new round of <quote>tasting</quote> of the providers. The intended geom class recognizes the metadata and brings the geom up.
(The above sequence of events is implementation-dependent but all existing code works like that, and it is supported by libraries.)
GEOM Command Structure
The helper <filename></filename> library exports <varname remap="structname">class_commands</varname> structure, which is an array of <varname remap="structname">struct g_command</varname> elements. Commands are of uniform format and look like:
verb [-options] geomname [other]
Common verbs are:
label — to write metadata to devices so they can be recognized at tasting and brought up in geoms
destroy — to destroy metadata, so the geoms get destroyed
Common options are:
<literal>-v</literal> : be verbose
<literal>-f</literal> : force
Many actions, such as labeling and destroying metadata can be performed in userland. For this, <varname remap="structname">struct g_command</varname> provides field <varname>gc_func</varname> that can be set to a function (in the same <filename>.so</filename>) that will be called to process a verb. If <varname>gc_func</varname> is NULL, the command will be passed to kernel module, to <function>.ctlreq</function> function of the geom class.
Geoms are instances of GEOM classes. They have internal data (a softc structure) and some functions with which they respond to external events.
The event functions are:
<function>.access</function> : calculates permissions (read/write/exclusive)
<function>.dumpconf</function> : returns XML-formatted information about the geom
<function>.orphan</function> : called when some underlying provider gets disconnected
<function>.spoiled</function> : called when some underlying provider gets written to
<function>.start</function> : handles I/O
These functions are called from the <function>g_down</function> kernel thread and there can be no sleeping in this context, (see definition of sleeping elsewhere) which limits what can be done quite a bit, but forces the handling to be fast.
Of these, the most important function for doing actual useful work is the <function>.start</function>() function, which is called when a BIO request arrives for a provider managed by a instance of geom class.
GEOM Threads
There are three kernel threads created and run by the GEOM framework:
<literal>g_down</literal> : Handles requests coming from high-level entities (such as a userland request) on the way to physical devices
<literal>g_up</literal> : Handles responses from device drivers to requests made by higher-level entities
<literal>g_event</literal> : Handles all other cases: creation of geom instances, access counting, <quote>spoil</quote> events, etc.
When a user process issues <quote>read data X at offset Y of a file</quote> request, this is what happens:


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks



English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/title
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/geom-class.pot, string 114