Samba

Was looking at using zstd for backup, and wanted to see the effect of different compression levels. I backed up my (built) bitcoin source, which is a decent representation of my home directory, but only weighs in 2.3GB. zstd -1 compressed it 71.3% ... [More] , zstd -22 compressed it 78.6%, and here’s a graph showing runtime (on my laptop) and the resulting size: zstandard compression (bitcoin source code, object files and binaries) times and sizes For this corpus, sweet spots are 3 (the default), 6 (2.5x slower, 7% smaller), 14 (10x slower, 13% smaller) and 20 (46x slower, 22% smaller). Spreadsheet with results here. [Less]

Introduction I've blogged a few of times about how Dracut and QEMU can be combined to greatly improve Linux kernel dev/test turnaround. My first post covered the basics of building the kernel, running dracut, and booting the resultant image with ... [More] qemu-kvm. A later post took a closer look at network configuration, and focused on bridging VMs with the hypervisor. Finally, my third post looked at how this technique could be combined with Ceph, to provide a similarly efficient workflow for Ceph development. In bringing this series to a conclusion, I'd like to introduce the newly released Rapido project. Rapido combines all of the procedures and techniques described in the articles above into a handful of scripts, which can be used to test specific Linux kernel functionality, standalone or alongside other technologies such as Ceph.  Usage - Standalone Linux VMThe following procedure was tested on openSUSE Leap 42.2 and SLES 12SP2, but should work fine on many other Linux distributions. Step 1: Checkout and BuildCheckout the Linux kernel and Rapido source repositories:~/> cd ~~/> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git~/> git clone https://github.com/ddiss/rapido.gitBuild the kernel (using a config provided with the Rapido source):~/> cp rapido/kernel/vanilla_config linux/.config~/> cd linux~/linux/> make -j6~/linux/> make modules~/linux/> INSTALL_MOD_PATH=./mods make modules_install~/linux/> sudo ln -s $PWD/mods/lib/modules/$(make kernelrelease) \ /lib/modules/$(make kernelrelease)Step 2: Configuration Install Rapido dependencies: dracut, qemu, brctl (bridge-utils) and tunctl.Edit rapido.conf, the master Rapido configuration file:~/linux/> cd ~/rapido~/rapido/> vi rapido.conf set KERNEL_SRC="/home//linux" set TAP_USER="" set MAC_ADDR1 to a valid MAC address, e.g. "b8:ac:24:45:c5:01" set MAC_ADDR2 to a valid MAC address, e.g. "b8:ac:24:45:c5:02" Configure the bridge and tap network devices. This must be done as root:~/rapido/> sudo tools/br_setup.sh~/rapido/> ip addr show br04: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 ... inet 192.168.155.1/24 scope global br0Step 3: Image Generation Generate a minimal Linux VM image which includes binaries, libraries and kernel modules for filesystem testing:~/rapido/> ./cut_fstests_local.sh... dracut: *** Creating initramfs image file 'initrds/myinitrd' done ***~/rapido/> ls -lah initrds/myinitrd-rw-r--r-- 1 ddiss users 30M Dec 13 18:17 initrds/myinitrdStep 4 - Boot! ~/rapido/> ./vm.sh+ mount -t btrfs /dev/zram1 /mnt/scratch[ 3.542927] BTRFS info (device zram1): disk space caching is enabled...btrfs filesystem mounted at /mnt/test and /mnt/scratchrapido1:/#  In a whopping four seconds, or thereabouts, the VM should have booted to a rapido:/# bash prompt. Leaving you with two zram backed Btrfs filesystems mounted at /mnt/test and /mnt/scratch.Everything, including the VM's root filesystem, is in memory, so any changes will not persist across reboot. Use the rapido.conf QEMU_EXTRA_ARGS parameter if you wish to add persistent storage to a VM.Although the network isn't used in this case, you should be able to observe that the VM's network adapter can be reached from the hypervisor, and vice-versa.rapido1:/# ip a show dev eth0 ... inet 192.168.155.101/24 brd 192.168.155.255 scope global eth0 ...rapido1:/# ping 192.168.155.1PING 192.168.155.1 (192.168.155.1) 56(84) bytes of data.64 bytes from 192.168.155.1: icmp_seq=1 ttl=64 time=1.97 msOnce you're done playing around, you can shutdown: rapido1:/# shutdown[ 267.304313] sysrq: SysRq : sysrq: Power Offrapido1:/# [ 268.168447] ACPI: Preparing to enter system sleep state S5[ 268.169493] reboot: Power down+ exit 0  Usage - Ceph vstart.sh cluster and CephFS client VMThis usage guide builds on the previous standalone Linux VM procedure, but this time adds Ceph to the mix. If you're not interested in Ceph (how could you not be!) then feel free to skip to the next section.  Step I - Checkout and BuildWe already have a clone of the Rapido and Linux kernel repositories. All that's needed for CephFS testing is a Ceph build:~/> git clone https://github.com/ceph/ceph~/> cd ceph~/ceph/> ./do_cmake.sh -DWITH_MANPAGE=0 -DWITH_OPENLDAP=0 -DWITH_FUSE=0 -DWITH_NSS=0 -DWITH_LTTNG=0~/ceph/> cd build~/ceph/build/> make -j4  Step II - Start a vstart.sh Ceph "cluster"Once Ceph has finished compiling, vstart.sh can be run with the following parameters to configure and locally start three OSDs, one monitor process, and one MDS.~/ceph/build/> OSD=3 MON=1 RGW=0 MDS=1 ../src/vstart.sh -i 192.168.155.1 -n...~/ceph/build/> bin/ceph -c status... health HEALTH_OK monmap e2: 1 mons at {a=192.168.155.1:40160/0} election epoch 4, quorum 0 a fsmap e5: 1/1/1 up {0=a=up:active} mgr no daemons active osdmap e10: 3 osds: 3 up, 3 in Step III - Rapido configurationEdit rapido.conf, the master Rapido configuration file:~/ceph/build/> cd ~/rapido~/rapido/> vi rapido.conf set CEPH_SRC="/home//ceph/src" KERNEL_SRC and network parameters were configured earlier Step IV - Image GenerationThe cut_cephfs.sh script generates a VM image with the Ceph configuration and keyring from the vstart.sh cluster, as well as the CephFS kernel module.~/rapido/> ./cut_cephfs.sh... dracut: *** Creating initramfs image file 'initrds/myinitrd' done *** Step V - Boot!Booting the newly generated image should bring you to a shell prompt, with the vstart.sh provisioned CephFS filesystem mounted under /mnt/cephfs:~/rapido/> ./vm.sh...+ mount -t ceph 192.168.155.1:40160:/ /mnt/cephfs -o name=admin,secret=...[ 3.492742] libceph: mon0 192.168.155.1:40160 session established...rapido1:/# df -h /mnt/cephfsFilesystem Size Used Avail Use% Mounted on192.168.155.1:40160:/ 1.3T 611G 699G 47% /mnt/cephfsCephFS is a clustered filesystem, in which case testing from multiple clients is also of interest. From another window, boot a second VM:~/rapido/> ./vm.sh  Further Use CasesRapido ships with a bunch of scripts for testing different kernel components: cut_cephfs.sh (shown above) Image: includes Ceph config, credentials and CephFS kernel module Boot: mounts CephFS filesystem cut_cifs.sh Image: includes CIFS (SMB client) kernel module Boot: mounts share using details and credentials specified in rapido.conf cut_dropbear.sh Image: includes dropbear SSH server Boot: starts an SSH server with SSH_AUTHORIZED_KEY cut_fstests_cephfs.sh Image: includes xfstests and CephFS kernel client Boot: mounts CephFS filesystem and runs FSTESTS_AUTORUN_CMD cut_fstests_local.sh (shown above) Image: includes xfstests and local Btrfs and XFS dependencies Boot: provisions local xfstest zram devices. Runs FSTESTS_AUTORUN_CMD cut_lio_local.sh Image: includes LIO, loopback dev and dm-delay kernel modules Boot: provisions an iSCSI target, with three LUs exposed cut_lio_rbd.sh Image: includes LIO and Ceph RBD kernel modules Boot: provisions an iSCSI target backed by CEPH_RBD_IMAGE, using target_core_rbd cut_qemu_rbd.sh Image: CEPH_RBD_IMAGE is attached to the VM using qemu-block-rbd Boot: runs shell only cut_rbd.sh Image: includes Ceph config, credentials and Ceph RBD kernel module Boot: maps CEPH_RBD_IMAGE using the RBD kernel client cut_tcmu_rbd_loop.sh Image: includes Ceph config, librados, librbd, and pulls in tcmu-runner from TCMU_RUNNER_SRC Boot: starts tcmu-runner and configures a tcmu+rbd backstore exposing CEPH_RBD_IMAGE via the LIO loopback fabric cut_usb_rbd.sh (see https://github.com/ddiss/rbd-usb) Image: usb_f_mass_storage, zram, dm-crypt, and RBD_USB_SRC Boot: starts the conf-fs.sh script from RBD_USB_SRC   Conclusion Dracut and QEMU can be combined for super-fast Linux kernel testing and development. Rapido is mostly just a glorified wrapper around these utilities, but does provide some useful tools for automated testing of specific Linux kernel functionality. If you run into any problems, or wish to provide any kind of feedback (always appreciated), please feel free to leave a message below, or raise a ticket in the Rapido issue tracker.Update 20170106:Add cut_tcmu_rbd_loop.sh details and fix the example CEPH_SRC path. [Less]

This week's "Git Rocks!" moment came while I was investigating how I could automatically add Reviewed-by, Acked-by, Tested-by, etc. tags to a given commit message.Git's interpret-trailers command is capable of testing for and manipulating arbitrary ... [More] Key: Value tags in commit messages.For example, appending Reviewed-by: MY NAME to the top commit message is as simple as running:> GIT_EDITOR='git interpret-trailers --trailer \ "Reviewed-by: $(git config user.name) <$(git config user.email)>" \ --in-place' git commit --amend Or with the help of a "git rb" alias, via: > git config alias.rb "interpret-trailers --trailer \ \"Reviewed-by: $(git config user.name) <$(git config user.email)>\" \ --in-place"> GIT_EDITOR="git rb" git commit --amendThe above examples work by replacing the normal git commit editor with a call to git interpret-trailers, which appends the desired tag to the commit message and then exits.My specific use case is to add Reviewed-by: tags to specific commits during interactive rebase, e.g.:> git rebase --interactive HEAD~3This brings up an editor with a list of the top three commits in the current branch. Assuming the aforementioned rb alias has been configured, individual commits will be given a Reviewed-by tag when appended with the following line:exec GIT_EDITOR="git rb" git commit --amendAs an example, the following will see three commits applied, with the commit message for two of them (d9e994e and 5f8c115) appended with my Reviewed-by tag.pick d9e994e ctdb: Fix CID 1398179 Argument cannot be negativeexec GIT_EDITOR="git rb" git commit --amendpick 0fb313c ctdb: Fix CID 1398178 Argument cannot be negative# ^^^^^^^ don't add a Reviewed-by tag for this one just yet pick 5f8c115 ctdb: Fix CID 1398175 Dereference after null checkexec GIT_EDITOR="git rb" git commit --amendBonus: By default, the vim editor includes git rebase --interactive syntax highlighting and key-bindings - if you press K while hovering over a commit hash (e.g. d9e994e from above), vim will call git show , making reviewing and tagging even faster!Thanks to: Upstream Git developers, especially those who implemented the interpret-trailers functionality. My employer, SUSE. [Less]

This week's "Git Rocks!" moment came while I was investigating how I could automatically add Reviewed-by, Acked-by, Tested-by, etc. tags to a given commit message.Git's interpret-trailers command is capable of testing for and manipulating arbitrary ... [More] Key: Value tags in commit messages.For example, appending Reviewed-by: MY NAME to the top commit message is as simple as running:> GIT_EDITOR='git interpret-trailers --trailer \ "Reviewed-by: $(git config user.name) <$(git config user.email)>" \ --in-place' git commit --amend Or with the help of a "git rb" alias, via: > git config alias.rb "interpret-trailers --trailer \ \"Reviewed-by: $(git config user.name) <$(git config user.email)>\" \ --in-place"> GIT_EDITOR="git rb" git commit --amendThe above examples work by replacing the normal git commit editor with a call to git interpret-trailers, which appends the desired tag to the commit message and then exits.My specific use case is to add Reviewed-by: tags to specific commits during interactive rebase, e.g.:> git rebase --interactive HEAD~3This brings up an editor with a list of the top three commits in the current branch. Assuming the aforementioned rb alias has been configured, individual commits will be given a Reviewed-by tag when appended with the following line:exec GIT_EDITOR="git rb" git commit --amendAs an example, the following will see three commits applied, with the commit message for two of them (d9e994e and 5f8c115) appended with my Reviewed-by tag.pick d9e994e ctdb: Fix CID 1398179 Argument cannot be negativeexec GIT_EDITOR="git rb" git commit --amendpick 0fb313c ctdb: Fix CID 1398178 Argument cannot be negative# ^^^^^^^ don't add a Reviewed-by tag for this one just yet pick 5f8c115 ctdb: Fix CID 1398175 Dereference after null checkexec GIT_EDITOR="git rb" git commit --amendBonus: By default, the vim editor includes git rebase --interactive syntax highlighting and key-bindings - if you press K while hovering over a commit hash (e.g. d9e994e from above), vim will call git show , making reviewing and tagging even faster!Thanks to: Upstream Git developers, especially those who implemented the interpret-trailers functionality. My employer, SUSE. [Less]

In my previous post, Rapid Linux Kernel Dev/Test with QEMU, KVM and Dracut, I described how build and boot a Linux kernel quickly, making use of port forwarding between hypervisor and guest VM for virtual network traffic.This post describes how to ... [More] plumb the Linux VM directly into a hypervisor network, through the use of a bridge.Start by creating a bridge on the hypervisor system:> sudo ip link add br0 type bridgeClear the IP address on the network interface that you'll be bridging (e.g. eth0).Note: This will disable network traffic on eth0!> sudo ip addr flush dev eth0Add the interface to the bridge: > sudo ip link set eth0 master br0Next up, create a TAP interface:> sudo /sbin/tunctl -u $(whoami)Set 'tap0' persistent and owned by uid 1001The -u parameter ensures that the current user will be able to connect to the TAP interface.Add the TAP interface to the bridge:> sudo ip link set tap0 master br0Make sure everything is up:> sudo ip link set dev br0 up> sudo ip link set dev tap0 upThe TAP interface is now ready for use. Assuming that a DHCP server is available on the bridged network, the VM can now obtain an IP address during boot via:> qemu-kvm -kernel arch/x86/boot/bzImage \ -initrd initramfs \ -device e1000,netdev=network0,mac=52:55:00:d1:55:01 \ -netdev tap,id=network0,ifname=tap0,script=no,downscript=no \ -append "ip=dhcp rd.shell=1 console=ttyS0" -nographicThe MAC address is explicitly specified, so care should be taken to ensure its uniqueness.The DHCP server response details are printed alongside network interface configuration. E.g.[ 3.792570] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX[ 3.796085] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready[ 3.812083] Sending DHCP requests ., OK[ 4.824174] IP-Config: Got DHCP answer from 10.155.0.42, my address is 10.155.0.1[ 4.825119] IP-Config: Complete:[ 4.825476] device=eth0, hwaddr=52:55:00:d1:55:01, ipaddr=10.155.0.1, mask=255.255.0.0, gw=10.155.0.254[ 4.826546] host=rocksolid-sles, domain=suse.de, nis-domain=suse.de...Didn't get an IP address? There are a few things to check: Confirm that the kernel is built with boot-time DHCP client (CONFIG_IP_PNP_DHCP=y) and E1000 network driver (CONFIG_E1000=y) support. Check the -device and -netdev arguments specify a valid e1000 TAP interface. Ensure that ip=dhcp is provided as a kernel boot parameter, and that the DHCP server is up and running. Happy hacking Update 20161223:Use 'ip' instead of 'brctl' to manipulate the bridge device - thanks Yagamy Light! [Less]

I use git send-email to submit patches to developer mailing lists. A reviewer may request a series of changes, in which case I find it easiest to make and test those changes locally, before sending a new round of patches to the mailing list with a ... [More] new version number:git send-email --subject-prefix="PATCH v4" --compose -14Assigning a version number to each round of patches allows me to add a change log for the entire patch-set to the introductory mail, e.g.:From: David Disseldorp Subject: [PATCH v4 00/14] add compression ioctl supportThis patch series adds support for the FSCTL_GET_COMPRESSION andFSCTL_SET_COMPRESSION ioctls, as well as the reporting of the currentcompression state via the FILE_ATTRIBUTE_COMPRESSED flag.Hooks are added to the Btrfs VFS module, which translates such requestsinto corresponding FS_IOC_GETFLAGS and FS_IOC_SETFLAGS ioctls.Changes since v3 (thanks for the feedback Jeremy):- fixed and split copy-chunk dest unlock change into separate commitChanges since v2:- Check for valid fsp file descriptors- Rebase atop filesystem specific selftest changes- Change compression fsctl permission checks to match Windows behaviour + Add corresponding smbtorture testChanges since v1:- Only use smb_fname and fsp args with GET_COMPRESSION. The smb_fname argument is only needed for the dosmode() code-path, fsp is used everywhere else.- Add an extra SetInfo(FILE_ATTRIBUTE_COMPRESSED) test.GIT: [PATCH v4 01/14] selftest/s3: expose share with FS applicable config...Change logs can also be added to individual patches using the --annotate parameter:git send-email --annotate --subject-prefix=PATCH v2 -1  Subject: [PATCH v2] common: add CephFS support...---Changes since version 1:- Remove -ceph parameter for check and rely on $FSTYP instead...diff --git a/README.config-sections b/README.config-sectionsPutting the change log between the first "---" and "diff --git a/..." lines ensures that it will be dropped when applying the patch via git-am. [update 2016-11-03]- Describe the --annotate parameter  [Less]

TL;DR: Parse and print .cat files: parsemscat Introduction Günther Deschner and myself are looking into the new Microsoft Printing Protocol [MS-PAR]. Printing always means you have to deal with drivers. Microsoft package-aware v3 print drivers and v4 ... [More] print drivers contain Microsoft Catalog files. A Catalog file (.cat) is a digitally-signed file. To be more precise it is a PKCS7 certificate with embedded data. Before I started to look into the problem understanding them I’ve searched the web, if someone already decoded them. I found a post by Richard Hughes: Building a better catalog file. Richard described some of the things we already discovered and some new details. It looks like he gave up when it came down to understand the embedded data and write an ASN.1 description for it. I started to decode the myth of Catalog files the last two weeks and created a tool for parsing them and printing what they contain, in human readable form. Details The embedded data in the PKCS7 signature of a Microsoft Catalog is a Certificate Trust List (CTL). Nikos Mavrogiannopoulos taught me ASN.1 and helped to create an ASN.1 description for the CTL. With this description I was able to start parsing Catalog files. CATALOG {} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- CATALOG_NAME_VALUE CatalogNameValue ::= SEQUENCE { name BMPString, -- UCS2-BE flags INTEGER, value OCTET STRING -- UCS2-LE } ... END mscat.asn The PKCS7 part of the .cat-file is the signature for the CTL. Nikos implemented support to get the embedded raw data from the PKCS7 Signature with GnuTLS. It is also possible to verify the signature using GnuTLS now! The CTL includes members and attributes. A member holds information about file name included in the driver package, OS attributes and often a hash for the content of the file name, either SHA1 or SHA256. I’ve written abstracted function so it is possible to create a library and a simple command line tool called dumpmscat. Here is an example of the output: CATALOG MEMBER COUNT=1 CATALOG MEMBER CHECKSUM: E5221540DC4B974F54DB4E390BFF4132399C8037 FILE: sambap1000.inf, FLAGS=0x10010001 OSATTR: 2:6.0,2:6.1,2:6.4, FLAGS=0x10010001 MAC: SHA1, DIGEST: E5221540DC4B974F54DB4E39BFF4132399C8037 In addition the CTL has normally a list of attributes. In those attributes are normally OS Flags, Version information and Hardware IDs. CATALOG ATTRIBUTE COUNT=2 NAME=OS, FLAGS=0x10010001, VALUE=VistaX86,7X86,10X86 NAME=HWID1, FLAGS=0x10010001, VALUE=usb\\vid_0ff0&pid_ff00&mi_01 Currently the projects only has a command line tool called: dumpmscat. And it can only print the CTL for now. I plan to add options to verify the signature, dump only parts etc. When this is done I will create a library so it can easily be consumed by other software. If someone is interested and wants to contribute. Something like signtool.exe would be nice to have. [Less]

TL;DR: Parse and print .cat files: parsemscat Introduction Günther Deschner and myself are looking into the new Microsoft Printing Protocol [MS-PAR]. Printing always means you have to deal with drivers. Microsoft package-aware v3 print drivers and v4 ... [More] print drivers contain Microsoft Catalog files. A Catalog file (.cat) is a digitally-signed file. To be more precise it is a PKCS7 certificate with embedded data. Before I started to look into the problem understanding them I’ve searched the web, if someone already decoded them. I found a post by Richard Hughes: Building a better catalog file. Richard described some of the things we already discovered and some new details. It looks like he gave up when it came down to understand the embedded data and write an ASN.1 description for it. I started to decode the myth of Catalog files the last two weeks and created a tool for parsing them and printing what they contain, in human readable form. Details The embedded data in the PKCS7 signature of a Microsoft Catalog is a Certificate Trust List (CTL). Nikos Mavrogiannopoulos taught me ASN.1 and helped to create an ASN.1 description for the CTL. With this description I was able to start parsing Catalog files. CATALOG {} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- CATALOG_NAME_VALUE CatalogNameValue ::= SEQUENCE { name BMPString, -- UCS2-BE flags INTEGER, value OCTET STRING -- UCS2-LE } ... END mscat.asn The PKCS7 part of the .cat-file is the signature for the CTL. Nikos implemented support to get the embedded raw data from the PKCS7 Signature with GnuTLS. It is also possible to verify the signature using GnuTLS now! The CTL includes members and attributes. A member holds information about file name included in the driver package, OS attributes and often a hash for the content of the file name, either SHA1 or SHA256. I’ve written abstracted function so it is possible to create a library and a simple command line tool called dumpmscat. Here is an example of the output: CATALOG MEMBER COUNT=1 CATALOG MEMBER CHECKSUM: E5221540DC4B974F54DB4E390BFF4132399C8037 FILE: sambap1000.inf, FLAGS=0x10010001 OSATTR: 2:6.0,2:6.1,2:6.4, FLAGS=0x10010001 MAC: SHA1, DIGEST: E5221540DC4B974F54DB4E39BFF4132399C8037 In addition the CTL has normally a list of attributes. In those attributes are normally OS Flags, Version information and Hardware IDs. CATALOG ATTRIBUTE COUNT=2 NAME=OS, FLAGS=0x10010001, VALUE=VistaX86,7X86,10X86 NAME=HWID1, FLAGS=0x10010001, VALUE=usb\\vid_0ff0&pid;_ff00&mi;_01 Currently the projects only has a command line tool called: dumpmscat. And it can only print the CTL for now. I plan to add options to verify the signature, dump only parts etc. When this is done I will create a library so it can easily be consumed by other software. If someone is interested and wants to contribute. Something like signtool.exe would be nice to have. [Less]

It took more than a year but finally Jakub and I released a new version of cmocka today. If you don’t know it yet, cmocka is a unit testing framework for C with support for mock objects! We set the version number to 1.1.0 because we have some new ... [More] features: Support to catch multiple exceptions Support to verify call ordering (for mocking) Support to pass initial data to test cases A will_return_maybe() function for ignoring mock returns Subtests for groups using TAP output Support to write multiple XML output files if you have several groups in a test and improved documentation We have some more features we are working on. I hope it will not take such a long time to release them. [Less]

Developing a USB gadget application that runs on Linux?Following a recent Ceph USB gateway project, I was looking at ways to test a Linux USB device without the need to fiddle with cables, or deal with slow embedded board boot times.Ideally USB ... [More] gadget testing could be performed by running the USB device code within a virtual machine, and attaching the VM's virtual USB device port to an emulated USB host controller on the hypervisor system.I was unfortunately unable to find support for virtual USB device ports in QEMU, so I abandoned the above architecture, and discovered dummy_hcd.ko instead.The dummy_hcd Linux kernel module is an excellent utility for USB device testing from within a standalone system or VM.dummy_hcd.ko offers the following features: Re-route USB device traffic back to the local system Effectively providing device loopback functionality USB high-speed and super-speed connection simulation It can be enabled via the USB_DUMMY_HCD kernel config parameter. Once the module is loaded, no further configuration is required. [Less]