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
rump into share/mk. This is to make it useful for all kernel
builders.
Note: we have waaay too many weird and wonderful ways of making
kernel code (monolithic kernel, modules, rump). There should be
only one way to build kernel code instead of a maze of twisty little
.mk files, all not quite alike. When that is fixed, this snippet can go
into the more generic .mk file.
modules in bootstrap, just add them. Load them later the same way
as the kernel does: module_init_class().
Change the signature of rump_module_init() to take a vector instead
of just one module. All modules in a DSO should be init'd at the
same time because they might depend on each other, and code outside
the rump kernel cannot know which way. (binary kernel modules are
still loaded with rump_sys_modctl() the usual way).
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.
the source files from src/sys/rump/librump/rumpuser to src/lib/librumpuser
(from where it is already built). Even so, keep rumpuser.h in
sys/rump/include for kernel source tree self-containment.
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?
in rumps is hard due to some archs having a colorful idea of what
they should be like. So temporarily disable build of components
using those for non-i386 (use the no-need-to-mess-with-setlists
approach).
pooka