Building RetroBSD Kernels with Kconfig

The document is based on article ” Building 4.4BSD Kernels with Config” by Samuel J. Leffler and Michael J. Karels, with modifications relevant to RetroBSD operating system and target PIC32 platform.


This document describes the use of kconfig utility to configure and create RetroBSD kernel images. It discusses the structure of kernel configuration files and how to configure systems with non-standard hardware configurations. Sections describing the preferred way to add new code to the kernel and how the system’s autoconfiguration process operates are included. An appendix contains a summary of the rules used by the kernel in calculating the size of system data structures, and also indicates some of the standard kernel size limitations (and how to change them). Other configuration options are also listed.

Revised September 2, 2015

1. Introduction

Kconfig is a tool used in building RetroBSD system images (the UNIX kernel). It takes a file describing a kernel’s tunable parameters and hardware support, and generates a collection of files which are then used to build a copy of UNIX appropriate to that configuration. Kconfig simplifies kernel maintenance by isolating system dependencies in a single, easy to understand, file.

This document describes the content and format of kernel configuration files and the rules which must be followed when creating these files. Example configuration files are constructed and discussed.

Later sections suggest guidelines to be used in modifying kernel source and explain some of the inner workings of the autoconfiguration process.

2. Configuration File Contents

A kernel configuration typically includes the following pieces of information:

  • architecture
  • cpu variant
  • board type
  • timezone (optional)
  • maximum number of users (optional)
  • location of the root file system
  • available hardware

Kconfig allows multiple kernel images to be generated from a single configuration description. Each kernel image is configured for identical hardware, but may have different locations for the root file system and, possibly, other system devices.

2.1. Architecture

The architecture indicates if the system is going to operate on a PIC32 microcontroller, or some other platform on which RetroBSD operates. The architecture is used to locate certain data files which are platform specific, and also to select rules used in constructing the resultant configuration files.

2.2. Cpu variant

The cpu variant indicates which, of possibly many, cpu’s the kernel is to operate on. For example, if the system is being configured as a PIC32, it could be running on a PIC32MX7, or other variants (not yet). Specifying more than one cpu type implies that the system should be configured to run on any of the cpu’s specified. For some architectures this is not possible and kconfig will print a diagnostic indicating such.

2.3. Board type

The board type is a moniker attached to the system, and identifies the specific board model, on which the system is to run. For example, for PIC32MX7 we have boards MAX32, SDXL, and so on. The system identifier selected is used to create a global C ”#define” which may be used to isolate board dependent pieces of code in the kernel.

2.4. Timezone

The timezone in which the system is to run is used to define the information returned by the gettimeofday(2) system call. This value is specified as the number of hours east or west of GMT. Negative numbers indicate a value east of GMT. The timezone specification may also indicate the type of daylight savings time rules to be applied. When timezone is not present in kernel configuration file, UTC is assumed (Greenwich).

2.5. Maximum number of users

The kernel allocates many system data structures at boot time based on the maximum number of users the system will support. This number is normally between 1 and 40, depending on the hardware and expected job mix. This parameter is optional. By default, 1 user is assumed.

2.6. Root file system location

When the kernel boots it must know the location of the root of the file system tree. This location and the part(s) of the disk(s) to be used for paging and swapping must be specified in order to create a complete configuration description. Kconfig uses many rules to calculate default locations for these items; these are described in Appendix B.

When a generic system is configured, the root file system is left undefined until the system is booted. In this case, the root file system need not be specified, only that the system is a generic system.

2.7. Hardware devices

When the kernel boots it goes through an autoconfiguration phase. During this period, the kernel searches for all those hardware devices which the system builder has indicated might be present. This probing sequence requires certain pieces of information such as register addresses, bus interconnects, etc. A system’s hardware may be configured in a very flexible manner or be specified without any flexibility whatsoever. Most people do not configure hardware devices into the kernel unless they are currently present on the machine, expect them to be present in the near future, or are simply guarding against a hardware failure somewhere else at the site (it is often wise to configure in extra disks in case an emergency requires moving one off a machine which has hardware problems).

The specification of hardware devices usually occupies the majority of the configuration file. As such, a large portion of this document will be spent understanding it. Section 6.3 contains a description of the autoconfiguration process, as it applies to those planning to write, or modify existing, device drivers.

2.8. Services

Several kernel facilities are configured in a manner like that used for hardware devices although they are not associated with specific hardware. These system options are configured as services. Some services allow an optional parameter that sets the limit on the number of instances of the device that are active simultaneously.

2.9. System options

Other than the mandatory pieces of information described above, it is also possible to include various optional kernel facilities or to modify system behavior and/or limits. Optional support is provided for disk quotas and tracing the performance of the virtual memory subsystem. Any optional facilities to be configured into the kernel are specified in the configuration file. The resultant files generated by kconfig will automatically include the necessary pieces of the system.

3. System Building Process

In this section we consider the steps necessary to build a kernel image. We assume the kernel source is located in the “$BSDSRC/sys” directory and that, initially, the system is being configured from source code.

Under normal circumstances there are 5 steps in building a kernel.

  1. Create a configuration file for the kernel.
  2. Make a directory for the kernel to be constructed in.
  3. Run kconfig on the configuration file to generate the files required to compile and load the kernel image.
  4. Construct the source code interdependency rules for the configured kernel with makedepend using make(1).
  5. Compile and load the kernel with make.

Steps 1 and 2 are usually done only once. When a kernel configuration changes it usually suffices to just run kconfig on the modified configuration file, rebuild the source code dependencies, and remake the kernel. Sometimes, however, configuration dependencies may not be noticed in which case it is necessary to clean out the relocatable object files saved in the kernel’s directory; this will be discussed later.

3.1. Creating a configuration file

Configuration files normally reside in the architecture-dependent directory like ” sys/pic32/max32”. A configuration file is most easily constructed by copying an existing configuration file and modifying it. The RetroBSD distribution contains a number of configuration files for well known boards; one may be suitable for you, or a copy of the generic configuration file may be edited.

Typically, the kernel build directory for a specific is placed as a subdirectory of sys/ARCH/BOARD, for example ” sys/pic32/max32”. The configuration and compilation procedure depends on the relative locations of directories within sys hierarchy, as most of the system code and the files created by kconfig use pathnames of the form ”../”. If the system files are not located in “$BSDSRC/sys”, it is desirable to make a symbolic link there for use in installation of other parts of the system that share files with the kernel.

When building the configuration file, be sure to include the items described in section 2. In particular, the architecture, cpu variant, board type, and root device must be specified. The specification of the hardware present may take a bit of work; particularly if your hardware is configured at non-standard places (e.g. device registers located at funny places or devices not supported by the system). Section 4 of this document gives a detailed description of the configuration file syntax, section 5 explains some sample configuration files, and section 6 discusses how to add new devices to the kernel. If the devices to be configured are not already described in one of the existing configuration files you should check the manual pages in section 4 of the UNIX Programmers Manual. For each supported device, the manual page synopsis entry gives a sample configuration line.

Once the configuration file is complete, run it through kconfig and look for any errors. Never try and use a kernel which kconfig has complained about; the results are unpredictable. For the most part, kconfig’s error diagnostics are self explanatory. It may be the case that the line numbers given with the error messages are off by one.

A successful run of kconfig on your configuration file will generate a number of files in the configuration directory. These files are:

  • A file to be used by make(1) in compiling and loading the kernel, Makefile.
  • One file for each possible kernel image for this machine, swapxxx.c, where xxx is the name of the kernel image, which describes where swapping, the root file system, and other miscellaneous system devices are located.
  • A collection of header files, one per possible device the system supports, which define the hardware configured.
  • A file containing the I/O configuration tables used by the kernel during its autoconfiguration phase, ioconf.c.
  • An assembly language file of interrupt vectors which connect interrupts from the machine’s external buses to the main system path for handling interrupts, and a file that contains counters and names for the interrupt vectors.

Unless you have reason to doubt kconfig, or are curious how the kernel’s autoconfiguration scheme works, you should never have to look at any of these files.

3.2. Constructing source code dependencies

When kconfig is done generating the files needed to compile and link your kernel it will terminate with a message of the form “Don’t forget to run make depend”. This is a reminder that you should change over to the configuration directory for the kernel just configured and type “make depend” to build the rules used by make to recognize interdependencies in the system source code. This will insure that any changes to a piece of the system source code will result in the proper modules being recompiled the next time make is run.

This step is particularly important if your site makes changes to the system include files. The rules generated specify which source code files are dependent on which include files. Without these rules, make will not recognize when it must rebuild modules due to the modification of a system header file. The dependency rules are generated by a pass of the C preprocessor and reflect the global system options. This step must be repeated when the configuration file is changed and kconfig is used to regenerate the system makefile.

3.3. Building the kernel

The makefile constructed by kconfig should allow a new kernel to be rebuilt by simply typing “make all”. For example, if you have named your kernel image “unix”, then “make all” will generate an image named “unix”. Alternate kernel image names are used when the root file system location and/or swapping configuration is done in more than one way. The makefile which kconfig creates has entry points for each kernel image defined in the configuration file. Thus, if you have configured “unix” to be a kernel with the root file system on an “sd” device and “hkunix” to be a kernel with the root file system on an “hk” device, then “make all” will generate binary images for each.

Note that the name of a kernel image is different from the board type. All kernel images are configured for the same system; only the information about the root file system and paging devices differ. (This is described in more detail in section 4.)

4. Configuration File Syntax

In this section we consider the specific rules used in writing a configuration file. A complete grammar for the input language can be found in Appendix A and may be of use if you should have problems with syntax errors.

A configuration file is broken up into three logical pieces:

  • configuration parameters global to all kernel images specified in the configuration file,
  • parameters specific to each kernel image to be generated, and
  • device specifications.

4.1. Global configuration parameters

The global configuration parameters are the architecture, cpu variants, options, timezone, board type, and maximum users. Each is specified with a separate line in the configuration file.

  • architecturetype

The kernel is to run on the architecture specified. No more than one architecture can appear in the configuration file. Currently the only legal value is pic32. Other variants are outdated (like vax, tahoe, hp300, i386, mips, pmax, luna68k and news3400).

  • cpumtype

This kernel is to run on the cpu type specified. More than one cpu type specification can appear in a configuration file. Legal type for a pic32 architecture is PIC32MX7.

  • options optionlist

Compile the listed optional code into the kernel. Options in this list are separated by commas. Possible options are listed at the top of the generic makefile. A line of the form “options FUNNY,HAHA” generates global ”#define”s −DFUNNY −DHAHA in the resultant makefile. An option may be given a value by following its name with “=”, then the value enclosed in (double) quotes. The following are major options are currently in use: CPU_KHZ=80000 (processor speed), and HZ=100 (rate of timer interrupt). There are additional options which are associated with certain peripheral devices; those are listed in the Synopsis section of the manual page for the device.

  • makeoptions optionlist

Options that are used within the kernel makefile and evaluated by make are listed as makeoptions. Options are listed with their values with the form “makeoptions name=value,name2=value2”. The values must be enclosed in double quotes if they include numerals or begin with a dash.

  • timezone number [ dst [ number ] ]

Specifies the timezone used by the system, optional. This is measured in the number of hours your timezone is west of GMT. EST is 5 hours west of GMT, PST is 8. Negative numbers indicate hours east of GMT. If you specify dst, the system will operate under daylight savings time. An optional integer or floating point number may be included to specify a particular daylight saving time correction algorithm; the default value is 1, indicating the United States. Other values are: 2 (Australian style), 3 (Western European), 4 (Middle European), and 5 (Eastern European). See gettimeofday(2) and ctime(3) for more information.

  • board name

This board is to be known as name. This is usually a short name like MAX32 (for chipKIT Max32 board) or SDXL (for Majenko SDXL board). This value is defined for use in conditional compilation, and is also used to locate an optional list of source files specific to this system.

  • maxusers number

The maximum expected number of simultaneously active users on this system is number. This number is used to size several kernel data structures. Default value is 1.

4.2. Kernel image parameters

Multiple kernel images may be specified in a single configuration file. The kernels will have the same global configuration parameters and devices, but the location of the root file system and other system specific devices may be different. A kernel image is specified with a “config” line:

  config sysname config-clauses

The sysname field is the name given to the loaded kernel image; almost everyone names their standard kernel image “unix”. The configuration clauses are one or more specifications indicating where the root file system is located and the number and location of paging devices.

A configuration clause is one of the following

  root [ on ] root-device
  swap [ on ] swap-device
  dumps [ on ] dump-device

(the “on” is optional.) Multiple configuration clauses are separated by white space; kconfig allows specifications to be continued across multiple lines by beginning the continuation line with a tab character. The “root” clause specifies where the root file system is located, the “swap” clause indicates swapping and paging area(s), and the “dumps” clause can be used to force kernel dumps to be taken on a particular device.

The device names supplied in the clauses may be fully specified as a device, unit, and file system partition; or underspecified in which case kconfig will use builtin rules to select default unit numbers and file system partitions.

The defaulting rules are a bit complicated as they are dependent on the overall kernel configuration. For example, the swap area need not be specified at all if the root device is specified; in this case the swap area is placed in the “b” partition of the same disk where the root file system is located. Appendix B contains a complete list of the defaulting rules used in selecting kernel configuration devices.

The device names are translated to the appropriate major and minor device numbers on a per-architecture basis. A file like ” sys/pic32/devices.kconf” is used to map a device name to its major block device number. The minor device number is calculated using the standard disk partitioning rules: on unit 0, while drive is minor device 0, partition “a” is minor device 1, partition “b” is minor device 2, and so on; for units other than 0, add 8 times the unit number to get the minor device.

If the default mapping of device name to major/minor device number is incorrect for your configuration, it can be replaced by an explicit specification of the major/minor device. This is done by substituting

  major x minor y

where the device name would normally be found. For example,

  config unix root on major 99 minor 1

Normally, the areas configured for swap space are sized by the kernel at boot time. If a non-standard size is to be used for one or more swap areas (less than the full partition), this can also be specified. To do this, the device name specified for a swap area should have a “size” specification appended. For example,

  config unix root on sd0 swap on sd0b size 1200

would force swapping to be done in partition “b” of “sd0” and the swap partition size would be set to 1200 sectors. A swap area sized larger than the associated disk partition is trimmed to the partition size.

To create a generic configuration, only the clause “swap generic” should be specified; any extra clauses will cause an error.

4.3. Device specifications

Each device attached to a machine must be specified to kconfig so that the kernel generated will know to probe for it during the autoconfiguration process carried out at boot time. Hardware specified in the configuration need not actually be present on the machine where the generated kernel is to be run. Only the hardware actually found at boot time will be used by the system.

A device specification takes one of the following forms:

  controller device-name device-info [ interrupt-spec ]
  device device-name device-info interrupt-spec

A “controller” is typically an SPI or I2C bus port. A “device” is an autonomous device which connects directly to the processor, or via controller (like SPI devices which connects through an SPI controller).

The device-name is one of the standard device names, as indicated in section 4 of the UNIX Programmers Manual, concatenated with the logical unit number to be assigned the device (the logical unit number may be different than the physical unit number indicated on the front of something like a disk; the logical unit number is used to refer to the UNIX device, not the physical unit number). For example, “sd0” is logical unit 0 of a storage device.

The device-info clause specifies how the hardware is connected in the interconnection hierarchy. On the PIC32, SD cards are connected through SPI ports. Thus, the following specification would be used:

  device  sd0     at spi2 pin RG9

Certain device drivers require extra information passed to them at boot time to tailor their operation to the actual hardware present. The line printer driver, for example, needs to know how many columns are present on each non-standard line printer (i.e. a line printer with other than 80 columns). The drivers for the terminal multiplexors need to know which lines are attached to modem lines so that no one will be allowed to use them unless a connection is present. For this reason, one last parameter may be specified to a device, a flags field. It has the syntax

  flags number

and is usually placed after other specifications. The number is passed directly to the associated driver. The manual pages in section 4 should be consulted to determine how each driver uses this value (if at all).

The exact syntax for each specific device is given in the Synopsis section of its manual page in section 4 of the manual.

4.4. Services

A number of drivers and software subsystems are treated like device drivers without any associated hardware. To include any of these pieces, a “service” specification must be used. A specification for a service takes the form

  service device-name [ howmany ]

Example of services is pty, the pseudo terminal driver (where the optional howmany value indicates the number of pseudo terminals to configure, 32 default).

5. Sample Configuration Files

In this section we will consider how to configure a sample PIC32 system for SDXL board. We then study the rules needed to configure a PIC32 to run in a networking environment.

5.1. PIC32 System

Our PIC32 kernel is configured with hardware peripherals avalable on SDXL board. Table 1 lists the pertinent hardware to be configured.

Table 1. PIC32MX Hardware support

Item Connection Name
UART port 1 cpu uart1
UART port 2 cpu uart2
SPI port 1 cpu spi1
SPI port 2 cpu spi2
SPI port 3 cpu spi3
SPI port 4 cpu spi4
microSD card spi2 sd0

We will call this board SDXL and construct a configuration file one step at a time.

The first step is to fill in the global configuration parameters. The target is a PIC32MX microcontroller, so the architecture is “pic32”. We will assume this kernel will run only on this one processor, so the cpu type is “PIC32MX7”. The options are empty since this is going to be a “vanilla” PIC32. The board type, as mentioned before, is “SDXL”, and the maximum number of users we plan to support is about 40. Thus the beginning of the configuration file looks like this:

  # SDXL board
  architecture "pic32"
  cpu          "PIC32MX7"
  board        SDXL

To this we must then add the specification for the kernel image. It will be our standard kernel with the root on “sd0” and swapping on the same drive as the root.

  config      unix    root on sd0

Finally, the hardware must be specified. Let us first just try transcribing the information from Table 1.

  device      uart1
  device      uart2
  controller  spi1
  controller  spi2
  controller  spi3
  controller  spi4
  device      sd0     at spi2 pin RG9

The completed configuration file for SDXL is available here: sys/pic32/sdxl/Config.

6. Adding New System Software

This section is not for the novice, it describes some of the inner workings of the configuration process as well as the pertinent parts of the system autoconfiguration process. It is intended to give those people who intend to install new device drivers and/or other kernel facilities sufficient information to do so in the manner which will allow others to easily share the changes.

This section is broken into four parts:

  • general guidelines to be followed in modifying kernel code,
  • how to add non-standard kernel facilities to RetroBSD,
  • how to add a device driver to RetroBSD, and

6.1. Modifying kernel code

If you wish to make site-specific modifications to the system it is best to bracket them with

  #ifdef SITENAME

to allow your source to be easily distributed to others, and also to simplify diff(1) listings. If you choose not to use a source code control system (e.g. SCCS, RCS), and perhaps even if you do, it is recommended that you save the old code with something of the form:

  #ifndef SITENAME

We try to isolate our site-dependent code in individual files which may be configured with service specifications.

Indicate processor-specific code with ”#ifdef PIC32MX7” (or other machine, as appropriate). RetroBSD underwent extensive work to make it extremely portable to machines with similar architectures − you may someday find yourself trying to use a single copy of the source code on multiple machines.

6.2. Adding non-standard kernel facilities

This section considers the work needed to augment kconfig’s data base files for non-standard kernel facilities. Kconfig uses a data base files.kconf that lists the source modules that may be required when building a system. The data base are taken from the directory in which kconfig is run, like sys/pic32/files.kconf. The lines in the files.kconf are normally of the form

  dir/source.c   type  option-list modifiers

for example,

  mips/dev/spi.c  optional spi

The type is one of standard or optional. Files marked as standard are included in all system configurations. Optional file specifications include a list of one or more system options that together require the inclusion of this module. The options in the list may be either names of devices that may be in the configuration file, or the names of system options that may be defined. An optional file may be listed multiple times with different options; if all of the options for any of the entries are satisfied, the module is included.

6.3. Adding device drivers to RetroBSD

The I/O system and kconfig have been designed to easily allow new device support to be added. The kernel source directories are organized as follows:

  sys/include architecture independent include files
  sys/kernel  architecture independent kernel source files
  sys/pic32   PIC32-specific code and drivers

Existing device drivers for the PIC32 reside in ” sys/pic32”. Any new device drivers should be placed in the appropriate source code directory and named so as not to conflict with existing devices. Normally, definitions for things like device registers are placed in a separate file in the same directory. For example, the “dh” device driver is named “dh.c” and its associated include file is named “dhreg.h”.

Once the source for the device driver has been placed in a directory, the file “files.kconf”, and possibly “devices.kconf” should be modified. The files.kconf file contains a line for each C source or binary-only file in the system. This file is architecture specific and is located in ” sys/ARCH/files.kconf”. The ” sys/ARCH/devices.kconf” file is used to map device names to major block device numbers. If the device driver being added provides support for a new disk you will want to modify this file (the format is obvious).

In addition to including the driver in the files.kconf file, it must also be added to the device configuration tables. These are located in ” sys/pic32/devsw.c”, or similar for architecture other than the PIC32. If you don’t understand what to add to this file, you should study an entry for an existing driver. Remember that the position in the device table specifies the major device number. The block major number is needed in the “devices.kconf” file if the device is a disk.

With the configuration information in place, your configuration file appropriately modified, and a system reconfigured and rebooted you should incorporate the shell commands needed to install the special files in the file system to the file ” sys/pic32/”. This is discussed in the document “Installing and Operating RetroBSD”.

Appendix A. Configuration File Grammar

The following grammar is a compressed form of the actual yacc(1) grammar used by kconfig to parse configuration files. Terminal symbols are shown all in upper case, literals are emboldened; optional clauses are enclosed in brackets, ”[” and ”]”; zero or more instantiations are denoted with “*”.

Configuration ::= [ Spec ; ]*

Spec          ::= Config_spec
                | Device_spec
                | trace
                | /* lambda */

/* configuration specifications */

Config_spec   ::= architecture ID
                | cpu ID
                | options Opt_list
                | board ID
                | System_spec
                | timezone [ − ] NUMBER [ dst [ NUMBER ] ]
                | timezone [ − ] FPNUMBER [ dst [ NUMBER ] ]
                | maxusers NUMBER

/* system configuration specifications */

System_spec   ::= config ID System_parameter [ System_parameter ]*

System_parameter ::= swap_spec | root_spec | dump_spec

swap_spec     ::= swap [ on ] swap_dev [ and swap_dev ]*

swap_dev      ::= dev_spec [ size NUMBER ]

root_spec     ::= root [ on ] dev_spec

dump_spec     ::= dumps [ on ] dev_spec

dev_spec      ::= dev_name | major_minor

major_minor   ::= major NUMBER minor NUMBER

dev_name      ::= ID [ NUMBER [ ID ] ]

/* option specifications */

Opt_list      ::= Option [ , Option ]*

Option        ::= ID [ = Opt_value ]

Opt_value     ::= ID | NUMBER

Mkopt_list    ::= Mkoption [ , Mkoption ]*

Mkoption      ::= ID = Opt_value

/* device specifications */

Device_spec   ::= device Dev_name Dev_info Int_spec
                | controller Dev_name Dev_info [ Int_spec ]
                | service Dev [ NUMBER ]

Dev_name      ::= Dev NUMBER

Dev           ::= ID

Dev_info      ::= Con_info [ Info ]*

Con_info      ::= at Dev NUMBER

Info          ::= drive NUMBER
                | flags NUMBER
                | pin PIN
                | pins PIN [ , PIN ]*

Int_spec      ::= priority NUMBER

Lexical Conventions

The terminal symbols are loosely defined as:

  • ID

One or more alphabetics, either upper or lower case, and underscore, “_”.


Approximately the C language specification for an integer number. That is, a leading “0x” indicates a hexadecimal value, a leading “0” indicates an octal value, otherwise the number is expected to be a decimal value. Hexadecimal numbers may use either upper or lower case alphabetics.


A floating point number without exponent. That is a number of the form “nnn.ddd”, where the fractional component is optional.

In special instances a question mark, ”?”, can be substituted for a “NUMBER” token. This is used to effect wildcarding in device interconnection specifications.

Comments in configuration files are indicated by a ”#” character at the beginning of the line; the remainder of the line is discarded.

A specification is interpreted as a continuation of the previous line if the first character of the line is tab.

Appendix B. Rules for Defaulting System Devices

When kconfig processes a “config” rule which does not fully specify the location of the root file system, paging area(s), and device for kernel dumps, it applies a set of rules to define those values left unspecified. The following list of rules are used in defaulting system devices.

  1. If a root device is not specified, the swap specification must indicate a “generic” system is to be built.
  2. If the root device does not specify a unit number, it defaults to unit 0.
  3. If the root device does not include a partition specification, it defaults to the “a” partition.
  4. If no swap area is specified, it defaults to the “b” partition of the root device.
  5. If no device is specified for processing argument lists, the first swap partition is selected.
  6. If no device is chosen for kernel dumps, the first swap partition is selected (see below to find out where dumps are placed within the partition).

The following table summarizes the default partitions selected when a device specification is incomplete, e.g. “sd0”.

Type Partition
root “a”
swap “b”
dumps “b”