It stuffs some nice sounds into the virtual kernel's /dev/audio,
reads the PCM from /dev/pad, and writes the data to stdout from
where it can be piped to audioplay to test that things actually
work.
If you want to know the secret message, you'll just have to run
this program ;)
and prints the address and name of the first peer encountered (if any):
ubt0 at uhub0 port 1
ubt0: Cambridge Silicon Radio Bluetooth USB Adapter, rev 2.00/19.15, addr 2
device ubt0, addr xx:xx:xx:xx:xx:xx
my peer: yy:yy:yy:yy:yy:yy, major class: 2 (phone)
peer name: Mokia maailmalta
kernel and provides the same device on the host with pud(4). I
can succesfully talk to my u3g device using tip(1) against the
server's devices. Some characters are lost here and there, though
(probably a problem with interrupt pipes in ugenhc). Once that
issues is solved, there is no reason why e.g. pppd (chat) could
not be used against the server.
Now, why would anyone want to do this instead of using the kernel
driver directly? Well, for one, on my laptop I run netbsd-5 which
doesn't have a u3g driver which supports the u3g hardware I have.
As anyone with half an eye can see, this is quite copypasted from
umserv and there is plenty of opportunity for uncopypasting for
the eager vi-wielder.
and attach it back to the host kernel using pud(4). The result is
pretty much indistinguisable from if kernel drivers were used.
It's possible to e.g. mount a file system backed by the userspace
block device driver:
golem> disklabel ./rumpsd0d
[...]
5 partitions:
# size offset fstype [fsize bsize cpg/sgs]
d: 1994752 0 unused 0 0 # (Cyl. 0 - 3895)
e: 1994512 240 MSDOS # (Cyl. 0*- 3895)
golem> s mount_msdos ./rumpsd0a /mnt
mount_msdos: "./rumpsd0a" is a non-resolved or relative path.
mount_msdos: using "/usr/home/pooka/src/umserv/rumpsd0a" instead.
mount_msdos: /usr/home/pooka/src/umserv/rumpsd0a on /mnt: Device not configured
golem> s mount_msdos ./rumpsd0e /mnt
mount_msdos: "./rumpsd0e" is a non-resolved or relative path.
mount_msdos: using "/usr/home/pooka/src/umserv/rumpsd0e" instead.
golem> df -h /mnt
Filesystem Size Used Avail %Cap Mounted on
/usr/home/pooka/src/umserv/rumpsd0e 974M 5.2M 968M 0% /mnt
etcetc.
terminal and host terminal stdin/stdout for human interaction.
Tipsy just simply shovels bits between the two. I can use my
JavaStation Krups (*) serial console with this ... without having
to worry abort those pesky usb drivers crashing my desktop kernel.
*) strictly speaking it's uwe's ;)
What makes this special is that the USB driver stack, the rum
driver, network subroutines and net80211 are running in userspace
in a rump kernel instead of in the host kernel.
an msdos file system which is located on a usb stick. What makes
this special is that the USB driver stack (and the file system
driver, of course) is run in rump instead of in the host kernel.
kernel cgd driver in an application which encrypts and decrypts
files. The cgd driver is running completely in userspace and
requires no special access privileges.
For example:
golem> dmesg > dmesg.txt
# write encrypted dmesg.txt to encrypted.img
golem> ./img2cgd write encrypted.img dmesg.txt
/cryptfile's passphrase:
# read encrypted.img and output decrypted contents to decrypted.txt
golem> ./img2cgd read encrypted.img decypted.txt
/cryptfile's passphrase:
golem> diff dmesg.txt decypted.txt
# but when entering a different password:
golem> ./img2cgd read encrypted.img decypted.txt
/cryptfile's passphrase:
golem> diff dmesg.txt decypted.txt
Binary files dmesg.txt and decypted.txt differ
Currently the utility writes the data length in a proprietary
format, but I'll convert it to use a real disklabel RSN. Then it
can be used to create cgd-encrypted disk images.
This program can later be used as a base for a utility to create
cgd-encrypted images of a standard NetBSD build. Idea for such a
tool and hence the inspiration for this simple example program from
Roland Dowdeswell.
pooka