S2sbind

From STRIDE Wiki
Jump to: navigation, search

The STRIDE Database Binder Utility

The s2sbind executable binds meta files (output from s2scompile) into a single .sidb file. In order for the binding process to succeed, the following conditions must be met:

  • All the target options (options starting with the "targ" prefix) used when invoking s2scompile must be consistent across all meta files. If present, the input database is taken as the target standard. If not present, then the first meta file processed is considered to be the target standard. Any subsequent meta files must match or an error is generated and it is not processed.
  • The binding process validates that scl descriptions of all types are consistent across all processed meta files. Certain conflicts (termed scl conflicts) will be flagged as warnings. Others will be flagged as errors and prevent the binding of the .meta file containing the conflict.


Syntax

   s2sbind [options] --output=database_file meta_file1 [meta_fileN]

Options

Option Description
--version Print version information.
--input_database=<file> An existing database (.sidb) file that is used as the starting point for the binding. Allows for incremental binding. By default the binding is not incremental.
--starting_suid=<N> Specifies the starting SUID. Default is 1. This option is ignored if an input_database was specified. Otherwise SUID autonumbering will start at this number. The number can be from 1 to 224-1. If the number of interfaces plus the starting SUID exceeds 224-1 then the number will "wrap" (roll over to 1 when 224 is called for).
--no_warning Suppress all warnings in the bind phase.
--output=<file>
-o<file>
Output database file. This option is required.
--options_file=<file> A file that contains command line options. The format is the same as the command line with the only addition that it could be split on multiple lines. A line starting with "#" symbol is ignored.

This option is necessary if the length of the command line string exceeds system limits. Otherwise it is provided only as a convenience.

SUID Numbering policies followed by s2sbind

When no input .sidb file is specified, s2sbind will assign interfaces SUIDs with the number given by the --starting_suid option, or 1 if no such option is specified. Interfaces are numbered in alphabetical order.

When an input database (.sidb) file is specified then the following will take place.

  • any --starting_suid option is ignored
  • For every interface in the input .sidb file with name <F> and SUID <N>, if <F> is in the .sidb file after the bind it will have SUID <N>, otherwise <N> is not used.
  • For every interface with a name not in the input .sidb file, each will be assigned a new SUID, starting with a number one greater than the greatest SUID in the input database. The new interfaces will be numbered according to their position in alphabetical order.
  • If a SUID has been explicitly specified (via a scl_msg or scl_func pragma), and the same SUID has already been automatically assigned to a function, the SUID of the later would be reassigned.

Examples

Refer to the Database Binding section of the Build Tools Examples.