I commented in recently on use of B# for Linux kernel modules, a B# VM can be done in 8K or less, has a small instruction set and can implement interrupt handlers.
On reflection this is more likely to be popular under the BSD’s who don’t have so much GPL philosophy to contend with.
Hardware manufacturers could provide one set of cross-platform B# binary drivers to run under MAC-OS X and *BSD - any architecture.
Hardware drivers need to make use of a very limited part of the kernel API, the main purpose of a hardware driver is to manage resources for the hardware and implement a standard API for that piece of hardware.
The B# glue layer - somewhat like ndis-wrappers - will be the layer that copes with evolving kernel API’s. And possibly also get ported to the linux kernel - and I really don’t know if this a good thing. Although Linus has commented against static kernel APIs to support binary modules, he has also refrained from heartily condemning suppliers of binary only kernel modules - often providing their on source-based API glue to the binary module.
While I’m a GPL fan and paying member of the FSF (not card carrying:- my bootable FSF membership card had developed some nasty blemishes making it unbootable by the time I came to need it, so I threw it away) I can see that simpler provision of hardware drivers could speed adoption of a broader selection of hardware platforms and operating systems.
It remains to been seen to what degree adoption on the wrong terms, i.e. without free software rights, is harmful. If more open source drivers follows the borader consumer adoption, it is maybe beneficial; I’m not yet at the level of Stallman where I can say "free software or no software" - I like my nvidia drivers, although I really wish they were free.
I’m just hoping that B# drivers would require enough meta data to link to make decompilation easy, I do want my source and the ability to fix bugs.
Which might mean that B# is just a glitzy gadget and for the kernel, a bad idea after all.