/usr/share/gtk-doc/html/ModemManager/ch02s02.html is in modemmanager-doc 1.0.0-2ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ModemManager Reference Manual: Probing</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
<link rel="home" href="index.html" title="ModemManager Reference Manual">
<link rel="up" href="ref-overview-modem-detection-and-setup.html" title="Modem detection and setup">
<link rel="prev" href="ref-overview-modem-detection-and-setup.html" title="Modem detection and setup">
<link rel="next" href="ch02s03.html" title="Port grabbing and Modem object creation">
<meta name="generator" content="GTK-Doc V1.20 (XML mode)">
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="10"><tr valign="middle">
<td width="100%" align="left" class="shortcuts"></td>
<td><a accesskey="h" href="index.html"><img src="home.png" width="16" height="16" border="0" alt="Home"></a></td>
<td><a accesskey="u" href="ref-overview-modem-detection-and-setup.html"><img src="up.png" width="16" height="16" border="0" alt="Up"></a></td>
<td><a accesskey="p" href="ref-overview-modem-detection-and-setup.html"><img src="left.png" width="16" height="16" border="0" alt="Prev"></a></td>
<td><a accesskey="n" href="ch02s03.html"><img src="right.png" width="16" height="16" border="0" alt="Next"></a></td>
</tr></table>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id-1.2.3.3"></a>Probing</h2></div></div></div>
<p>
Whenever a new device is detected by ModemManager, port probing process will
get started, so that we can determine which kind of ports we have, and also
which plugin we need to use for the specific device. Devices may expose one or
more ports, and all of them will follow the same probing logic.
</p>
<p>
The whole probing process, including pre-probing and post-probing filters, is
implemented in the core ModemManager daemon. Plugins will just configure their
own special needs in the probing process, so that only the steps required by the
given plugin are executed. For example, plugins which do not support RS232
devices will not need AT-based vendor or product filters.
</p>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="id-1.2.3.3.4"></a>Pre-probing filters</h3></div></div></div>
<p>
Pre-probing filters are those which control whether the probing, as
requested by the specific plugin, takes place.
</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
<p><span class="emphasis"><em>Allowed vendor IDs</em></span></p>
<p>
Plugins can provide a list of udev-reported vendor IDs to be used as
pre-probing filters. If the vendor ID reported by the device via udev
is found in the list provided by the plugin, port probing will be
launched as requested by the given plugin.
</p>
<p>
This filter is specified by the <span class="type">MM_PLUGIN_ALLOWED_VENDOR_IDS</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Product IDs</em></span></p>
<p>
Plugins can provide a list of udev-reported pairs of vendor and product
IDs to be used as pre-probing filters.
</p>
<p>
If the vendor ID and product ID pair reported by the device via udev is
found in the list of 'allowed' pairs provided by the plugin, port probing
will be launched as requested by the given plugin. This additional filter
should be used when the plugin is expected to work only with a given
specific product of a given vendor.
</p>
<p>
If the vendor ID and product ID pair reported by the device via udev is
found in the list of 'forbidden' pairs provided by the plugin, port probing
will not be launched by this plugin. This additional filter
should be used when the plugin supports all devices of a given vendor
except for some specific ones.
</p>
<p>
These filters are specified by the <span class="type">MM_PLUGIN_ALLOWED_PRODUCT_IDS</span>
and <span class="type">MM_PLUGIN_FORBIDDEN_PRODUCT_IDS</span> properties in the
<span class="structname">MMPlugin</span> object provided by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Subsystems</em></span></p>
<p>
Plugins can specify which subsystems they expect, so that we filter out
any port detected with a subsystem not listed by the plugin.
</p>
<p>
This filter is specified by the <span class="type">MM_PLUGIN_ALLOWED_SUBSYSTEMS</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Drivers</em></span></p>
<p>
Plugins can specify which drivers they expect, so that we filter out
any port detected being managed by a driver not listed by the plugin.
</p>
<p>
Plugins can also specify which drivers they do not expect, so that we
filter out any port detected being managed by a driver listed by the plugin.
</p>
<p>
These filters are specified by the <span class="type">MM_PLUGIN_ALLOWED_DRIVERS</span>
and <span class="type">MM_PLUGIN_FORBIDDEN_DRIVERS</span> properties in the
<span class="structname">MMPlugin</span> object provided by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>udev tags</em></span></p>
<p>
Plugins can provide a list of udev tags, so that we filter out
any port detected which doesn't expose any of the given tags.
</p>
<p>
This filter is specified by the <span class="type">MM_PLUGIN_ALLOWED_UDEV_TAGS</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
</ul></div>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="id-1.2.3.3.5"></a>Probing sequence</h3></div></div></div>
<p>
Whenever all pre-probing filters of a given plugin pass, ModemManager will run
the probing sequence as requested by the specific plugin. The main purpose of the
probing sequence step is to determine the type of port being probed, and also
prepare the information required in any expected post-probing filter.
</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
<p><span class="emphasis"><em>Custom initialization</em></span></p>
<p>
This property allows plugins to provide an asynchronous method which will get
executed as soon as the AT port gets opened. This method may be used for any
purpose, like running an early command in the ports as soon as possible, or
querying the modem for info about the port layout.
</p>
<p>
This configuration is specified by the <span class="type">MM_PLUGIN_CUSTOM_INIT</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>AT allowed</em></span></p>
<p>
This boolean property allows plugins to specify that they expect and support
AT serial ports.
</p>
<p>
This configuration is specified by the <span class="type">MM_PLUGIN_ALLOWED_AT</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Single AT expected</em></span></p>
<p>
This boolean property allows plugins to specify that they only expect and support
one AT serial port. Whenever the first AT port is grabbed, any remaining AT probing
in ports of the same device will get cancelled.
</p>
<p>
This configuration is specified by the <span class="type">MM_PLUGIN_ALLOWED_SINGLE_AT</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Custom AT probing</em></span></p>
<p>
This property allows plugins to specify custom commands to check whether a port
is AT or not. By default, the 'AT' command will be used if no custom one specified.
</p>
<p>
This configuration is specified by the <span class="type">MM_PLUGIN_CUSTOM_AT_PROBE</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>QCDM allowed</em></span></p>
<p>
This boolean property allows plugins to specify that they expect and support
QCDM serial ports.
</p>
<p>
This configuration is specified by the <span class="type">MM_PLUGIN_ALLOWED_QCDM</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Check Icera support</em></span></p>
<p>
This boolean property allows plugins to specify that they want to have the Icera
support checks included in the probing sequence. They can afterwards get the result
of the support check to decide whether they want to create a Icera-based modem
object or not.
</p>
<p>
This configuration is specified by the <span class="type">MM_PLUGIN_ICERA_PROBE</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
</ul></div>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="id-1.2.3.3.6"></a>Post-probing filters</h3></div></div></div>
<p>
Post-probing filters are required to identify whether a plugin can handle a given
modem, in special cases where the information retrieved from udev is either not
enough or wrong. This covers, for example, RS232 modems connected through a RS232
to USB converter, where udev-reported vendor ID is that of the converter, not the
one of the modem.
</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
<p><span class="emphasis"><em>Allowed vendor strings</em></span></p>
<p>
Plugins can provide a list of vendor strings to be used as post-probing
filters. If the vendor string reported by the device via AT commands
is found in the list provided by the plugin, the plugin will report that
it can handle this modem.
</p>
<p>
This filter is specified by the <span class="type">MM_PLUGIN_ALLOWED_VENDOR_STRINGS</span>
property in the <span class="structname">MMPlugin</span> object provided
by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Product strings</em></span></p>
<p>
Plugins can provide a list of pairs of vendor and product
strings to be used as post-probing filters.
</p>
<p>
If the vendor and product string pair reported by the device via AT
commands is found in the 'allowed' list provided by the plugin, the
plugin will report that it can handle this modem. This additional filter
should be used when the plugin is expected to work only with a given
specific product of a given vendor.
</p>
<p>
If the vendor and product string pair reported by the device via AT
commands is found in the 'forbidden list provided by the plugin, the
plugin will report that it cannot handle this modem. This additional filter
should be used when the plugin supports all devices of a given vendor, except for some specific ones.
</p>
<p>
These filters are specified by the <span class="type">MM_PLUGIN_ALLOWED_PRODUCT_STRINGS</span>
and <span class="type">MM_PLUGIN_FORBIDDEN_PRODUCT_STRINGS</span> properties in the
<span class="structname">MMPlugin</span> object provided by the plugin.
</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Icera support</em></span></p>
<p>
Plugins can specify that they only support Icera-based modems, or that they
do not support any Icera-based modem. When either of this configurations is
enabled, the Icera support checks will be included in the
probing sequence, and the result of the check will help to determine whether
the plugin supports the modem or not.
</p>
<p>
This filter is specified by the <span class="type">MM_PLUGIN_ALLOWED_ICERA</span> and
<span class="type">MM_PLUGIN_FORBIDDEN_ICERA</span> properties in the
<span class="structname">MMPlugin</span> object provided by the plugin.
</p>
</li>
</ul></div>
<div class="note"><p>
Plugins which require post-probing filters will always be sorted last, and
therefore they will be the last ones being checked for pre-probing filters. This
is due to the fact that we need to assume that these plugins aren't able to
determine port support just with pre-probing filters, as we want to avoid
unnecessary probing sequences launched. Also note that the Generic plugin is
anyway always the last one in the list.
</p></div>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="id-1.2.3.3.7"></a>Probing setup examples</h3></div></div></div>
<div class="example">
<a name="id-1.2.3.3.7.2"></a><p class="title"><b>Example 1. Probing setup for a plugin requiring udev-based vendor/product checks</b></p>
<div class="example-contents"><pre class="programlisting">
G_MODULE_EXPORT MMPlugin *
mm_plugin_create (void)
{
static const gchar *subsystems[] = { "tty", NULL };
static const guint16 vendor_ids[] = { 0xabcd, 0 };
static const mm_uint16_pair product_ids[] = {
{ 0x1234, 0xffff }
};
static const gchar *vendor_strings[] = { "vendor", NULL };
return MM_PLUGIN (
g_object_new (MM_TYPE_PLUGIN_IRIDIUM,
MM_PLUGIN_NAME, "Example",
/* Next items are pre-probing filters */
MM_PLUGIN_ALLOWED_SUBSYSTEMS, subsystems,
MM_PLUGIN_ALLOWED_VENDOR_IDS, vendor_ids,
MM_PLUGIN_ALLOWED_PRODUCT_IDS, product_ids,
/* Next items are probing sequence setup */
MM_PLUGIN_ALLOWED_AT, TRUE,
/* No post-probing filters */
NULL));
}
</pre></div>
</div>
<br class="example-break"><div class="example">
<a name="id-1.2.3.3.7.3"></a><p class="title"><b>Example 2. Probing setup for a plugin requiring AT-probed vendor/product checks</b></p>
<div class="example-contents"><pre class="programlisting">
G_MODULE_EXPORT MMPlugin *
mm_plugin_create (void)
{
static const gchar *subsystems[] = { "tty", NULL };
static const gchar *vendor_strings[] = { "vendor", NULL };
static const mm_str_pair product_strings[] = { "another-vendor", "product xyz" };
return MM_PLUGIN (
g_object_new (MM_TYPE_PLUGIN_IRIDIUM,
MM_PLUGIN_NAME, "Example",
/* Next items are pre-probing filters */
MM_PLUGIN_ALLOWED_SUBSYSTEMS, subsystems,
/* Next items are probing sequence setup */
MM_PLUGIN_ALLOWED_AT, TRUE,
/* Next items are post-probing filters */
MM_PLUGIN_VENDOR_STRINGS, vendor_strings,
MM_PLUGIN_PRODUCT_STRINGS, product_strings,
NULL));
}
</pre></div>
</div>
<br class="example-break"><div class="example">
<a name="id-1.2.3.3.7.4"></a><p class="title"><b>Example 3. Probing setup for a plugin with custom initialization requirements</b></p>
<div class="example-contents"><pre class="programlisting">
static gboolean
parse_custom_at (const gchar *response,
const GError *error,
GValue *result,
GError **result_error)
{
if (error) {
*result_error = g_error_copy (error);
return FALSE;
}
/* Otherwise, done. And also report that it's an AT port. */
g_value_init (result, G_TYPE_BOOLEAN);
g_value_set_boolean (result, TRUE);
return TRUE;
}
static const MMPortProbeAtCommand custom_at_probe[] = {
{ "AT+SOMETHING", parse_custom_at },
{ NULL }
};
G_MODULE_EXPORT MMPlugin *
mm_plugin_create (void)
{
static const gchar *subsystems[] = { "tty", NULL };
static const guint16 vendor_ids[] = { 0xabcd, 0 };
return MM_PLUGIN (
g_object_new (MM_TYPE_PLUGIN_EXAMPLE,
MM_PLUGIN_NAME, "Example",
/* Next items are pre-probing filters */
MM_PLUGIN_ALLOWED_SUBSYSTEMS, subsystems,
MM_PLUGIN_ALLOWED_VENDOR_IDS, vendor_ids,
/* Next items are probing sequence setup */
MM_PLUGIN_CUSTOM_AT_PROBE, custom_at_probe,
MM_PLUGIN_ALLOWED_AT, TRUE,
/* No post-probing filters */
NULL));
}
</pre></div>
</div>
<br class="example-break">
</div>
</div>
<div class="footer">
<hr>
Generated by GTK-Doc V1.20</div>
</body>
</html>
|