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.
KAUTH_REQ_NETWORK_NFS_EXPORT and KAUTH_REQ_NETWORK_NFS_SVC, and use them
to replace two KAUTH_GENERIC_ISSUSER calls in the NFS code.
Also replace two more with KAUTH_SYSTEM_MKNOD, where appropriate.
Documetnation and examples updated. More to come.
Make the FreeBSD and Linux compat code convert the parameters to their
native representation and call the native routines.
Remove KAUTH_PROCESS_SCHEDULER_GET/SET.
Update documentation and examples.
XXX: For now, only the Linux compat code does the priority conversion
XXX: right.
Linux priority conversion code from yamt@, thanks!
Okay yamt@.
words, don't pass an action and a request, and just use a single action to
indicate what is the operation in question.
This is the first step in fixing PR/37986, which calls for policy/priority
checking in the secmodel code. Right now we're lacking room for another
parameter required to make a decision, and this change makes room for such.
Don't hand all the argv options to fuse_main() - it's only interested
in the ones we haven't parsed ourselves.
These changes make the initiator compile and perform discovery successfully
on FreeBSD 6.3. Full login doesn't work yet due to a KSE related bug.
- Add a KAUTH_PROCESS_SCHEDULER action, to handle scheduler related
requests, and add specific requests for set/get scheduler policy and
set/get scheduler parameters.
- Add a KAUTH_PROCESS_KEVENT_FILTER action, to handle kevent(2) related
requests.
- Add a KAUTH_DEVICE_TTY_STI action to handle requests to TIOCSTI.
- Add requests for the KAUTH_PROCESS_CANSEE action, indicating what
process information is being looked at (entry itself, args, env,
open files).
- Add requests for the KAUTH_PROCESS_RLIMIT action indicating set/get.
- Add requests for the KAUTH_PROCESS_CORENAME action indicating set/get.
- Make bsd44 secmodel code handle the newly added rqeuests appropriately.
All of the above make it possible to issue finer-grained kauth(9) calls in
many places, removing some KAUTH_GENERIC_ISSUSER requests.
- Remove the "CAN" from KAUTH_PROCESS_CAN{KTRACE,PROCFS,PTRACE,SIGNAL}.
Discussed with christos@ and yamt@.
Been running in my tree for over a month at least.
Reviewed and okay yamt@, and special thanks to him as well as rittera@
for making this possible through fixing NDIS to not call fork1() with
l1 != curlwp.
can find.
If the initiator discovers too many targets for it to handle
(currently more than 16), then truncate to the maximum with a loud
warning message, rather than aborting.
In practice, this means that multiple targets can now be used with the
NetBSD iSCSI initiator.
% ls -laR /mnt/inspiron1300.wherever.co.uk/
total 192
drwxr-xr-x 2 agc agc 512 Dec 11 08:53 .
drwxr-xr-x 2 root wheel 0 Jan 1 1970 ..
drwxr-xr-x 2 agc agc 512 Dec 11 08:53 target0
drwxr-xr-x 2 agc agc 512 Dec 11 08:53 target1
/mnt/inspiron1300.wherever.co.uk/target0:
total 576
drwxr-xr-x 2 agc agc 512 Dec 11 08:53 .
drwxr-xr-x 2 agc agc 512 Dec 11 08:53 ..
lrw-r--r-- 1 agc agc 44 Dec 11 08:53 hostname -> inspiron1300.wherever.co.uk
lrw-r--r-- 1 agc agc 9 Dec 11 08:53 ip -> 10.4.0.42
lrw-r--r-- 1 agc agc 16 Dec 11 08:53 product -> NetBSD iSCSI
-rw-r--r-- 1 agc agc 104857600 Dec 11 08:53 storage
lrw-r--r-- 1 agc agc 43 Dec 11 08:53 targetname -> iqn.1994-04.org.netbsd.iscsi-target:target0
lrw-r--r-- 1 agc agc 8 Dec 11 08:53 vendor -> NetBSD
lrw-r--r-- 1 agc agc 4 Dec 11 08:53 version -> 0
/mnt/inspiron1300.wherever.co.uk/target1:
total 576
drwxr-xr-x 2 agc agc 512 Dec 11 08:53 .
drwxr-xr-x 2 agc agc 512 Dec 11 08:53 ..
lrw-r--r-- 1 agc agc 44 Dec 11 08:53 hostname -> inspiron1300.wherever.co.uk
lrw-r--r-- 1 agc agc 0 Dec 11 08:53 ip ->
lrw-r--r-- 1 agc agc 16 Dec 11 08:53 product -> NetBSD iSCSI
-rw-r--r-- 1 agc agc 52428800 Dec 11 08:53 storage
lrw-r--r-- 1 agc agc 43 Dec 11 08:53 targetname -> iqn.1994-04.org.netbsd.iscsi-target:target1
lrw-r--r-- 1 agc agc 8 Dec 11 08:53 vendor -> NetBSD
lrw-r--r-- 1 agc agc 4 Dec 11 08:53 version -> 0
%
Ok, ok, a few more words about it: stop holding puffs_cc as a holy
value and passing it around to almost every possible place (popquiz:
which kernel variable does this remind you of?). Instead, pass
the natural choice, puffs_usermount, and fetch puffs_cc via
puffs_cc_getcc() only in routines which actually need it. This
not only simplifies code, but (thanks to the introduction of
puffs_cc_getcc()) enables constructs which weren't previously sanely
possible, say layering as a curious example.
There's still a little to do on this front, but this was the major
fs interface blast.
and we need to add 1 to it to get the size of the LUN.
Revert Max LBA calculation when returning the Maximum LBA from the target
to the iinitiator, following an email conversation with Jonathan Kollasch,
who points out a number of things:
+ the NetBSD scsipi driver reads the value returned by the drive and adds
one to it, so that standard SCSI drives return the 0-based Max LBA in a
READ CAPACITY command.
+ it is up to the initiator to add 1 to the Max LBA to find out the size
of the LUN (Jonathan verified this by using the UNH iSCSI initiator on
to a NetBSD target)
+ an analogous change to the NetBSD target (revision 1.34 of
disk.c) is needed.
libpuffs.
With a round of applause to Antti Kantee for helping out with puffs
debugging, and a huge thank you to Greg Oster, who has fixed numerous
bugs over the last week (unfortunately, the bugs are all mine), and
provided enthusiasm and drive.
Right now, the initiator is fulling working for only a single target,
and should be considered to be in a state of flux. Having said that,
Greg completed a run of build.sh with the storage on the iSCSI target,
and found times to be within 0.5% of direct attached storage. Cache
effects apply.
The initiator should be portable to everything that uses the FUSE
interface. That's right - a portable iSCSI initiator.
Storage (LUNs exported by the target) is, at the present time,
presented as a regular file called "storage". This will likely
change in the future.
% priv obj/iscsifs -u agc inspiron1300 /mnt &
[1] 13158
inspiron1300.wherever.co.uk: 10.4.0.42:3260,1 iqn.1994-04.org.netbsd.iscsi-target:target0
inspiron1300.wherever.co.uk: 10.4.0.42:3260,1 iqn.1994-04.org.netbsd.iscsi-target:target1
% ls -al /mnt/inspiron1300.wherever.co.uk/target0/
total 576
drwxr-xr-x 2 agc agc 512 Nov 8 21:07 .
drwxr-xr-x 2 agc agc 512 Nov 8 21:07 ..
lrw-r--r-- 1 agc agc 44 Nov 8 21:07 hostname -> inspiron1300.wherever.co.uk
lrw-r--r-- 1 agc agc 9 Nov 8 21:07 ip -> 10.4.0.42
lrw-r--r-- 1 agc agc 16 Nov 8 21:07 product -> NetBSD iSCSI
-rw-r--r-- 1 agc agc 104857088 Nov 8 21:07 storage
lrw-r--r-- 1 agc agc 43 Nov 8 21:07 targetname -> iqn.1994-04.org.netbsd.iscsi-target:target0
lrw-r--r-- 1 agc agc 8 Nov 8 21:07 vendor -> NetBSD
lrw-r--r-- 1 agc agc 4 Nov 8 21:07 version -> 0
FFS needs a block device, and so vnconfig can be used to sit on top of
the regular file.
% mount -vv | grep iscsifs
/dev/puffs on /mnt type puffs|refuse:iscsifs (nosuid, nodev, fsid: 0xcb04/0x6acb, reads: sync 0 async 0, writes: sync 0 async 0)
% priv vnconfig vnd0 /mnt/inspiron1300.wherever.co.uk/target0/storage
% priv mount /dev/vnd0a /iscsi
% df
Filesystem 1K-blocks Used Avail %Cap Mounted on
/dev/dk0 28101396 21491182 5205146 80% /
kernfs 1 1 0 100% /kern
procfs 4 4 0 100% /proc
ptyfs 1 1 0 100% /dev/pts
/dev/puffs 0 0 0 100% /mnt
/dev/vnd0a 99214 8209 86045 8% /iscsi
% mount -vv | grep iscsi
/dev/puffs on /mnt type puffs|refuse:iscsifs (nosuid, nodev, fsid: 0xcb04/0x6acb, reads: sync 0 async 0, writes: sync 0 async 0)
/dev/vnd0a on /iscsi type ffs (local, fsid: 0xe00/0x78b, reads: sync 1 async 0, writes: sync 2 async 0)
servers. Calling daemon() (i.e. fork()ing) inside a library can
cause nice surprises for e.g. threaded programs. As discussed with
Greg Oster & others.
avoid wasting unbelievable amounts of memory, set the blocksize to
something more believable. Should fix the memset-part to act only
up to the size the file is extended to, though.
pooka