The top of a top-down hierarchical structure of subdirectories is called which of the following?

IV.F.1.c Tree-structured [hierarchical] directories

Tree-structured directories [sometimes called hierarchical directories] allow users to create directories within directories at will. A master or root directory contains pointers to main subdirectories. Data files can be mentioned in these subdirectories, or further, sub-subdirectories can be created. The flexibility of this arrangement allows users to group files [or even directories] in ways which are meaningful to them, thus aiding navigation in the directory structure and making it easier to name files [names can be duplicated so long as the same name is not used in the same directory] and to find them [if the user has a good organizing principle for the directories he or she creates]. This form of file directory organization is now widely used in popular operating systems such as Unix and its look alikes. Graphical user interfaces in which directories are presented as file folders make the directory structure more transparent, as the user simply selects a directory by clicking on it and then sees the next level of material [which may be either files or further subdirectories, or both].

5.1.4.1 Hyperbolic Node Graph

Similar to Lamping et al.'s hyperbolic tree browser [31], we created a 3D tree which at the beginning is centered around the root directory of the selected user's hard disk. Directories are displayed as spheres, with lines connecting parent and children directories. The user can then choose to add another user's directory tree, whose directories will be displayed in a different color than the first user's. Common directories will be displayed in a third color. Even though the data set we had was anonymized, it used consistent hash codes so that we were able to identify common directories and file extensions.

As opposed to a hyperbolic tree, we map our directory nodes onto invisible, concentric, and evenly spaced spheres around the root directory. Since we use a surround visualization system, there is no need to limit the virtual width, as opposed to 2D graphs which cannot extend beyond the edge of the screen or paper they are displayed on.

When the user clicks on a directory node, the graph automatically recenters on this directory. This allows the user to study a particular part of the tree, even one that is deep down in the tree, while still taking advantage of the 3D space around the user to spread out the nodes of interest.

As shown on the screenshot in Fig. 15, a click on a directory node with a different button brings up four wheel graphs, showing information about the file types in the selected directory, as well as in the entire subtree including and below the selected directory. For each of the above, there is one graph showing the number of files, and one showing the accumulated file size. The wheel graphs are cylinders with bars extending out from the center, the length of the bars indicating file size or number of files of a certain type. We distinguish 11 different file types, based on file extensions: audio, binary, library, text, code, compressed, internet, office, image, video, and other. The user can select between a linear scale and a logarithmic scale for the length of the bars. We find that the wheel graphs occlude less of the scene than traditional bar graphs would, while still conveying the data similarly well. In addition to the wheel graphs, we display a text box which lists file sizes and other information about the selected directory in numeric form. Figure 16 shows what our hyperbolic graph looks like in the StarCAVE.

29.5 File system structure

Files store data in the form of programs, documents, spread-sheets, and so on. They are organized into a tree structure. The top of the structure is the root directory and each branch is called a subdirectory. This structure makes finding files easier than having all files stored in the one directory.

The route through the tree structure to a given file is known as the pathname and reference to files external to the current directory is possible by using the correct path. The pathname for a given file is traced through the tree structure from the root directory to the location of the file.

Test run 29.9 shows an example list of a top-level directory. The prompt should be set-up to display the current directory. In this case, the DOS prompt is C:\>.

The top level directory in this case contains various sub-directories such as DOCS, WINDOWS, PSP and TURBO. Each of these directories contains files and/or sub-directories. The function of each directory is normally obvious from its name. For example, the DOS directory contains DOS program, help manuals and system files, the WINDOWS directory contains programs for Microsoft Windows.

The top-level directory is the root directory, and is given the name \. A small section of the directory hierarchy is given in Figure 29.2. Notice that there are four sub-directories below the root directory and that below the DOCS directory there are three sub-directories NOTES, CLASSES and ADMIN. There is also one sub-directory below WINDOWS. To identify the directories a pathname must be given. The full pathname each directory is:

All these directories are stored on the hard disk which is labelled as C:, thus the full pathname, with the disk drive, of the directories are:

These pathnames are the full pathnames and are absolute pathnames. It is also possible to specify a relative pathname. With relative pathname the name given does not have the preceding top-level directory [\]. For example, if we are in the GAMES directory the relative pathname for the DATA directory is CHESS\DATA and if we are in the WINDOWS directory the relative pathname for the SYSTEM directory is simply SYSTEM.

The Root Directory

The role of the FAT table is that of keeping track of how and where data is allocated. It does not contain any information about the nature of the file to which the data belonged. For that purpose there is another structure called the root directory whose sole purpose is that of storing file names, sizes, dates, times and a number of other attributes. In a FAT16 file system, the root directory [or simply the root from now on] is allocated in a fixed amount of space and a fixed position right between the FAT [second copy] and the first data cluster [Figure 14.3].

Since both position and size [number of sectors] are fixed, the maximum number of files [or directory entries] in the root directory is limited and determined when formatting the media. Each sector allocated to the root will allow for 16 file entries to be documented where each entry will require a block of 32 bytes as represented in Figure 14.4.

The Name and Extension fields are the most obvious if you are familiar with the older Microsoft operating systems using the 8:3 conventions [the two fields need only to be padded with spaces and the dot can be discarded].

The Attributes field is composed of a group of flags with meanings shown in Table 14.1.

Table 14.1. File attributes in a directory entry

The Time and Date fields refer to the last time the file was modified and must be encoded in a special format to compress all the information in just two 16-bit words [Tables 14.2 and 14.3].

Table 14.2. Time encoding in a directory entry field

Table 14.3. Date encoding in a directory entry field

Notice how the date field encoding does not allow for the code 0x0000 to be interpreted as a valid date, helping provide clues to the file system when the field is not used or corrupted.

The First Cluster field provides the fundamental link with the FAT table. The 16-bit word it contains is nothing but the number of the cluster [could be the only or the first in a chain] containing the file data.

Finally, the Size field contains in a long integer [32-bit], the size in bytes of the file data.

Looking at the first character of the file name in a directory entry we can also tell whether the entry is currently in use, in which case an actual ASCII printable character is present, or whether the entry is empty, in which case the first byte is a zero, and we can also assume that the list of files is terminated as the file system proceeds sequentially using all entries in order. There is a third possibility: in fact, when a file is removed from the directory the first character is simply replaced by a special code [0xE5]. This indicates that the contents of the entry are no longer valid, and the entry can be re-used for a new file at the next opportunity. When browsing through the list though, searching for a file, we should continue as more active entries might follow.

1.2.1.2 SBT and Scala

Simple Build Tool [SBT] is a build system similar to Maven, but which is commonly used to compile sources written in Scala. NetLogo is compiled with SBT, since its most recent versions are written in Scala.

Unlike Maven, which manages dependencies by using pom.xml files, SBT uses files written in Scala to determine the structure of the project and its dependencies. One of the most important such files is build.sbt, which may be found in the project root directory. SBT uses the same online repositories as Maven to download the right dependencies for compiling and packaging extensions in development. The primary SBT file, named build.sbt, uses Netlogo-Extension-Plugin14, which automatically downloads the right Netlogo.jar file and provides a simplified interface for packaging extensions.

Since NetLogo version 5.3.1 can only be compiled with Java 7, we must tell SBT where to find this version on your device: sbt -Java-home /path/to/Java/home.

Even though it may not be immediately useful in our case, note that it is possible to tell SBT which version of Java it should use to run Java programs by adding the following lines to build.sbt:

fork in run := true

JavaHome in run := Some[file[“/path/to/Java/home/”]]

Finally, the extension is compiled by running the sbt compile command, and the .jar is built by calling sbt package.

35.3 Directory structure

Files are used to store permanent information which are used by programs. The information could be schematics, text files, documents, and so on. In order to facilitate the recovery of files they are arranged into directories in a structure that is similar to an office filing system. The UNIX file directory structure takes the form of a tree with the root directory at the highest level. This top level, or root directory, is given the name /. An example of a directory system is shown in Figure 35.1. In this case there are 5 sub-directories below the root level, these are bin, usr, etc, dev and user. Below the usr directory there are 3 sub-directories, these are lib, adm and bin. In this case, all the users of the system have been assigned to a sub-directory below the users directory, that is, bill_b,fred_a and alan_g.

The full pathname of the bill_b directory is /users/bill_b and the full pathname of the adm directory is /usr/admin. Files can be stored within a directory structure. Figure 35.2 shows an example structure.

In this case, the full pathname of the FORTRAN file prog.ftn is:

and the full pathname of the c directory is:

Files and sub-directories can also be referred to in a relative manner, where the directory is not reference to the top-level [it thus does not have a preceding /]. For example, if the user was in the bill_b directory then the relative path for the C program file1.c is:

7.1.2 tf.summary.image

"tf.summary.image" is an API of the "tf.summary" module used for writing an image summary. Its result can display on the images dashboard of TensorBoard. The syntax of “tf.summary.image” is expressed as follows:

The following program examples explain how to use the "tf.summary.image" API. Please download the test image from the link below and unzip it under the root directory. //drive.google.com/open?id=1cC45twI3a5AkBYYE6Qb3ZV3uCPlw9eL6

First read an image [airplane.png]

Write an image to a log file and display it on TensorBoard, as shown in Fig. 7.4

Five images including airplane_zoom.png, plane_flip.png, plane_color.png, plane_rot.png, and plane.png are written to the log file and displayed on TensorBoard at once, as shown in Fig. 7.5

Write five images including airplane_zoom.png, airplane_flip.png, airplane_color.png, airplane_rot.png, and airplane.png to the log file in separate steps and display on TensorBoard, as shown in Fig. 7.6

4.2.2 Files

Managing various objects, such as information in disks, display monitors, and keyboards, is an important operating system function. To hide peculiarities of these objects, the operating system presents the programmer with a nice, clean abstract model of device-independent files. A file must be opened before it can be read, written, and closed. Therefore, system calls are needed to create, remove, open, read, write, and close files.

Most operating systems provide a hierarchical file system for users to manage their files. Files can be grouped together into a directory, which is also a special file and can be grouped into another directory. This model also gives rise to a hierarchical file system, as shown in Figure 4.3.

Every file in the file hierarchy can be specified by its given path name from the top of the hierarchy, the root directory. Such absolute path names consist of the list of directories that must be traversed from the root directory to get to the file, with special symbols such as slashes separating the components. In Figure 4.3, the path for file passwd is denoted as /etc/ passwd. The leading slash indicates that the path is starting from the root directory. As an aside, some systems use a back slash[\] instead of a regular slash[/] as the separator in path names.

At every instant, each process has a current working directory, in which path names not beginning with a slash are looked for. In Figure 4.3, if etc is the current directory, then the path name passwd denotes the same file as etc/passwd. A process can change its working directory by issuing a system call specifying the new working directory.

If several users can access the same computer, the system needs to provide a means for users to protect the privacy of their files. In many systems, a user can specify the type of protection, such as read, write, and execution, against certain groups of users. Before a file can be read or written, it must be opened, at which time the protection is checked. If the access is permitted, the system returns a small integer called a file descriptor or handle to use in subsequent operations. Otherwise, an error code is returned.

Some operating systems such as UNIX and MS-DOS provide a special file abstraction to allow users to perform I/O without knowing all details of the hardware. Special files can be read and written in the same way as regular files are read and written. Special files are categorized into two types: block special files and character special files. Block special files are used to model devices that consist of a collection of randomly addressable blocks, such as disks. By opening a block special file and reading, a program can directly access the desired block on the device without regard to the structure of the file system contained on it.

Character special files are used to model devices that consist of character streams rather than fixed-size randomly addressable blocks. Terminals, line printers, and network interfaces are typical examples of character special files. A program can interact with the user's terminal by reading and writing the corresponding character special file. In UNIX and MS-DOS, when a process is started up, file descriptor 0, called standard input, is normally arranged to refer to the terminal for the purpose of reading. File descriptor 1, called standard output, refers to the terminal for writing. File descriptor 2, called standard error, also refers to the terminal for output but is used only for writing error messages.

In some operating systems, such as UNIX, there is a special concept called pipe, which is a pseudo-file that can be used to connect two processes together. When a process wants to send data to another process, it writes on the pipe as though it were an input file for the second process. Thus, communication between processes looks very much like ordinary file reads and writes.

5.3 Case Study: AT91SAM9G45 Boot Process

The AT91SAM9G45 evaluation board embeds an internal read-only memory [ROM], which is mapped at address 0x0040 0000 and contains the bootloader and the program SAM-BA [16, 13]. The bootloader integrates different boot programs that interface with different memory components on board. The embedded bootloader is used upon reset if the boot mode select pin is detected at high level [logical 1]; otherwise, the memory connected on the Chip Select 0 of the External Bus Interface is used.

When the embedded bootloader is used, it will perform the following actions upon system reset:

1.

It performs minimum hardware initialization—say, starts the on-chip RC oscillator and enables the 32,768 Hz slow clock oscillator.

It attempts to boot from NVM devices. The sequence below is used to download an application from an external storage medium into internal static RAM [SRAM]:

The SD Card Boot program is executed first. It looks for a boot.bin file in the root directory of a FAT12/16/32 formatted SD card. If such a file is found, code is downloaded into the internal SRAM. Go to step 4.

If the SD card is not well formatted or if a boot.bin file is not found, the NAND Flash Boot program is then executed to search for a valid application in the NAND flash memory. If a valid application [described by a sequence of seven valid ARM exception vectors2 ] is found, this application is downloaded into the internal SRAM. Go to step 4.

If no valid application is found, the Data-Flash Boot program is then executed to search for a valid application in a data-flash memory connected to the SPI. If a valid application is found, it is downloaded into the internal SRAM. Go to step 4.

If no valid application is found in NVM devices, SAM-BA Boot is then executed. It initializes the USB High Speed device port and the debug unit serial port. It then starts automatic baud rate detection, waiting for transactions either on the USB High Speed device port or on the debug unit serial port.

It remaps memory, which lays out the internal SRAM bank to 0x0.

It jumps to the first instruction of the application in SRAM and run it.

In practice, a developer may want to use the option given in step 3 to program embedded software to the NAND flash memory device. Once an ELF object is on the board, the option given in step 2b could be used to load and run the application.

13.2.1 Test environment management

For providing a cross-platform and convenient environment to build, develop, and manage the test bed, ComNetsEmu provides a preconfigured VM environment managed by Vagrant in an easy-to-use workflow. Vagrant is a free and open-source tool to manage and share portable virtual machine environments [266]. Vagrant supports GNU/Linux, macOS, and Windows as hosting OS. By default, Vagrant can use Virtualbox, Hyper-V, Docker containers, VMware, and others as the VM hypervisors. The configuration and provisioning steps of the ComNetsEmu VM is described in the

When the VM is created for the first time, it requires some time to download the base VM image and install all software dependencies via the built-in Bash installer script. After the build and provision of the emulation VM is completed, the commands listed in 2 can be utilized to use the VM:

By default the directory containing the

ComNetsEmu and its built-in example programs require following minimal dependencies:

Mininet [v2.3.0d6 and beyond] with its minimal dependencies: Since the Mininet latest version [with Python 3 support] has no official binary release and the ComNetsEmu wants to use the latest stable release as soon as possible, the Mininet Python module is installed from source code. As minimal dependencies, Open vSwitch, Stanford OpenFlow1.0 reference controller, and Wireshark with OpenFlow support are also installed.

Ryu SDN controller [v4.32 and beyond] [268]

Docker Engine-Community [19.03.0 and beyond]

Docker SDK Python [v3.7.2 and beyond] [269]

Wireguard [0.0.20190702-wg1 bionic and beyond]

All these requirements are installed automatically with the installer located in

with -a option. Each component can additionally be installed separately with proper options if desired. The help information can be printed with -h option of the installer.