Now, let's say you start a rump server and configure a memory disk
on it. Remote (as in TCP remote) clients may now access that
memory.
cloudy, my apps are scattered and they're cloudy
they have no borders, no boundaries
our SCSIPI driver stack. Currently we pretend to be a single CD
controller with an optional host file as the image, but I guess
the sky's the limit.
dmesg porn:
NetBSD 5.99.39 (RUMP-ROAST) #0: Mon Aug 23 11:38:16 CEST 2010
pooka@pain-rustique.localhost:/usr/allsrc/src/sys/rump/librump/rumpkern
total memory = unlimited (host limit)
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "rumpclk" frequency 100 Hz quality 0
root file system type: rumpfs
mainbus0 (root)
scsitest0 at mainbus0
scsibus0 at scsitest0: 2 targets, 1 lun per target
cd0 at scsibus0 target 1 lun 0: <RUMPHOBO, It's a LIE, 0.00> cdrom removable
that we can attach a power management handler. The handler prevents
a suspend if the watchdog is active, to be consistent with other
watchdog drivers.
As discussed on tech-kern.
with rumpfs_puffs for prehistoric reasons which are no longer valid
(namely, only fs components existed back then and there was no /dev
support in rump fs namespace).
This is a curious driver in the sense that unlike all other current
device drivers, it does not require vfs. This is because the driver
is controlled via bluetooth, which is controlled via PF_BLUETOOTH
sockets (as opposed to a /dev node).
considering our ugen driver doesn't support isochronous write.
kern/25960 seems to contain a patch and could be investigated for that)
* add a dirty rotten hack which makes interrupt transfers of >16
work for me
module which is linked into the kernel and cannot be unloaded.
The main purpose is to get the proper constructors run and create
any /dev nodes necessary for said component. Once more of the
kernel (e.g. networking stack and device drivers) are converted to
MODULE and devfs pops up from somewhere, rump components can be
retired.
and signal the root hub interrupt only once we are succesfully able
to open the device node. This makes it possible to insert a device
after the rump kernel was booted and have it succesfully attach
(does not make detach possible yet, though, as there are some
ugen and host kernel uhci/ohci/ehci evil crashies with that).
XXX: optimally, match would fail if there is a permanent error in
opening. However, it is difficult to figure out the difference
between the device backing ugen not being present, a transient
error in opening and a permanent error in opening. For example,
which of the latter two would EPERM be? And, ugen returns ENXIO
if the device is not present, but how would be know that's really
the case and not some other ENXIO from elsewhere in the stack?
