Integrate Blog OS with CrossBus VGA Text

The Blog OS is a great series of source to create a small operating system in rust language.

And CrossBus is a lower level actor computing model compatible with bare metal, can efficiently and asynchronously transmit / share data between components which may make a difference in OS development.

Integration Target

Only the first 3 posts (by Vga-text) will be touched in the section. So if you don't familiar with post-1 or post-2 you'd better take a look beforehand.

Pre-Requisites

Since crossbus use rust alloc crate,

• we must add alloc to the build-std field of .cargo/config.toml:

build-std = ["core", "compiler_builtins", "alloc"]

• mark the global allocator
  • add emballoc to your dependencies
  • specified the global_allocator: ``

    
    #![allow(unused)]
    fn main() {
       #[global_allocator]
       static ALLOCATOR: emballoc::Allocator<4096> = emballoc::Allocator::new();
    }
    

Overview of Actor's Life Cycle

Here represents a simple illustration :

actor::create --> ActorRegister --> push to global static Register --> dropped when closed

Changes

• Switch to static Register instead of lazy_static / spinlocks

recall that the blog os defines a glocal Writer with lazy_static and guarded with spin::Mutex

#![allow(unused)]
fn main() {
lazy_static! {
    pub static ref WRITER: Mutex<Writer> = Mutex::new(Writer {
        column_position: 0,
        color_code: ColorCode::new(Color::Yellow, Color::Black),
        buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
    });
}
}

with crossbus, you

• don't have to worry about static / lock, or some stuff like that;

• access any type implemented trait Actor with global static mutable/sharing reference;

Details

So the dependencies spin or lazy_static is not necessary here:

#![allow(unused)]
fn main() {
// define the message
pub struct Msg(String);

// impl the Message trait
impl message::Message for Msg {}

impl Actor for Writer {
    type Message = Msg;

		// normally create the Writer
    fn create(_: &mut Context<Self>) -> Self {
        Writer {
            column_position: 0,
            color_code: ColorCode::new(Color::Yellow, Color::Black),
            buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
        }
    }

    // this line is not necessary though
    // a syntax must
    //
    // since we dont use an writer instance then
    // call this method
    fn action(&mut self, _: Self::Message, _: &mut Context<Self>) {}
}
}

According to the illustration above, once the actor is created, you can access it as glocal static item, and downcast it to the original type Writer, and you don't manually lock the Writer ( crossbus has assure its exclusively access)

#![allow(unused)]
fn main() {
// mark the writer's actor id
// used to get writer from `crossbus::Register`
static WRITERID: AtomicUsize = AtomicUsize::new(0);

// if Writer is not created
// then create one
if WRITERID.load(Ordering::Acquire) == 0 {
		let (_, id) = Writer::start();
		WRITERID.store(id, Ordering::Release);
}

// find the actor by id and
Register::get(WRITERID.load(Ordering::Acquire))
		.unwrap()
		// downcast the actor as mutable reference of Writer
		.downcast_mut::<Writer, _>(
				// here pass a closure,
				// writer is a mutable reference
				|writer: &mut Writer| {
						// and use it write string to display
						writer.write_fmt(args).unwrap();
						Ok(())
				},
		);
}

Results

go the project directory and use cargo run, you will see:

Code

this is the a section of integrating blog os with crossbus, the full code is at here

Content

All posted articles:

• integrate blog os with crossbus vga text
• announcing a new runtime less platform less actor computing model

Integrate Blog OS with CrossBus VGA Text

The Blog OS is a great series of source to create a small operating system in rust language.

And CrossBus is a lower level actor computing model compatible with bare metal, can efficiently and asynchronously transmit / share data between components which may make a difference in OS development.

Integration Target

Only the first 3 posts (by Vga-text) will be touched in the section. So if you don't familiar with post-1 or post-2 you'd better take a look beforehand.

Pre-Requisites

Since crossbus use rust alloc crate,

• we must add alloc to the build-std field of .cargo/config.toml:

build-std = ["core", "compiler_builtins", "alloc"]

• mark the global allocator
  • add emballoc to your dependencies
  • specified the global_allocator: ``

    
    #![allow(unused)]
    fn main() {
       #[global_allocator]
       static ALLOCATOR: emballoc::Allocator<4096> = emballoc::Allocator::new();
    }
    

Overview of Actor's Life Cycle

Here represents a simple illustration :

actor::create --> ActorRegister --> push to global static Register --> dropped when closed

Changes

• Switch to static Register instead of lazy_static / spinlocks

recall that the blog os defines a glocal Writer with lazy_static and guarded with spin::Mutex

#![allow(unused)]
fn main() {
lazy_static! {
    pub static ref WRITER: Mutex<Writer> = Mutex::new(Writer {
        column_position: 0,
        color_code: ColorCode::new(Color::Yellow, Color::Black),
        buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
    });
}
}

with crossbus, you

• don't have to worry about static / lock, or some stuff like that;

• access any type implemented trait Actor with global static mutable/sharing reference;

Details

So the dependencies spin or lazy_static is not necessary here:

#![allow(unused)]
fn main() {
// define the message
pub struct Msg(String);

// impl the Message trait
impl message::Message for Msg {}

impl Actor for Writer {
    type Message = Msg;

		// normally create the Writer
    fn create(_: &mut Context<Self>) -> Self {
        Writer {
            column_position: 0,
            color_code: ColorCode::new(Color::Yellow, Color::Black),
            buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
        }
    }

    // this line is not necessary though
    // a syntax must
    //
    // since we dont use an writer instance then
    // call this method
    fn action(&mut self, _: Self::Message, _: &mut Context<Self>) {}
}
}

According to the illustration above, once the actor is created, you can access it as glocal static item, and downcast it to the original type Writer, and you don't manually lock the Writer ( crossbus has assure its exclusively access)

#![allow(unused)]
fn main() {
// mark the writer's actor id
// used to get writer from `crossbus::Register`
static WRITERID: AtomicUsize = AtomicUsize::new(0);

// if Writer is not created
// then create one
if WRITERID.load(Ordering::Acquire) == 0 {
		let (_, id) = Writer::start();
		WRITERID.store(id, Ordering::Release);
}

// find the actor by id and
Register::get(WRITERID.load(Ordering::Acquire))
		.unwrap()
		// downcast the actor as mutable reference of Writer
		.downcast_mut::<Writer, _>(
				// here pass a closure,
				// writer is a mutable reference
				|writer: &mut Writer| {
						// and use it write string to display
						writer.write_fmt(args).unwrap();
						Ok(())
				},
		);
}

Results

go the project directory and use cargo run, you will see:

Code

this is the a section of integrating blog os with crossbus, the full code is at here

CrossBus a New Runtime Less Platform Less Actor Computing Model

Hello, Rustaceans!

after months' work on this project, the first version of crossbus is out. A Rust library for Platform-less Runtime-less Actor-based Computing, an implementation of Actor Computing Model, with the concept that

• Runtime-Less

  crossbus neither provides runtime for downstream app execution, nor accesses the system interface. Going Runtime less doesn't mean execution without runtime, but more precisely, no built-in runtime, but allow any runtime.

• libstd-free and Bare-Metal Compatible

  links to no std library, no system libraries, no libc, and a few upstream libraries.

  All crossbus need to run on a bare metal is a allocator. (see example)

• Platform-less by Runtime-less

  bypass the limitation of runtime implementation which often relies on a specific platform or operating system abstraction, crossbus can go platform-less.

• Future-oriented Routine and Events

  crossbus defines a set of types and traits to allow asynchronous tasks manipulation, actor communication, message handling, context interaction and etc all are asynchronous. That means you can run a future on a bare metal

• Real-time Execution Control

  taking the advantage of the design of future routine, each poll and events alongside can be intercepted for each spawned task during execution, with which more execution control is possible.

Currently crossbus is in its alpha version, all APIs and architecture is not stable yet, and evolves very quickly.

to get a taste of crossbus, you can check out the examples which demonstrates how to use crossbus in std/ no-std/ web-assembly/ etc.

Feel Free to Contribute to this repository! All issues / bugs-report / feature-request / etc are welcome!

Possible Questions and Answers

• why create crossbus

  this is the most natural and obvious question, I guess, about crossbus,
  why not use some frameworks like actix rotor go-actor or orleans, they are mature and have rich ecosystem? besides the features mentioned above, crossbus is aimed at extending actor-based computing to a lower level with more compatibility.

• why split off runtime

  it could be the most obvious question after the first, most of frameworks built upon some kind of runtime or targeting for certain runtime . why crossbus take a different road?

  Imagine a scenario that you want certain functionality of a project, but when looking at the document/ source code of the project, it requires a specific runtime. and in order to use it the integration either

  • change my current runtime (change a lot of stuff, not a good idea)
  • set up it as a service and access it via network ( more complex )
  • compile it into dynamic/static library and load/link it ( most we do )
  • split the crate features off the runtime

  the last option seems better, right? benefiting from this, more limits can be pushed :

  • less dependent on developing platform
  • less code redundancy and complexity
  • more compatible and efficient

• possible application of crossbus

  with the help of powerful actor computing model with lower level and more compatible support, there are some potentially fields:

  • web assembly
  • operating system development
  • embedded development
  • game development
  • IoT
  • web infrastructure

• Is it a defeater to shift runtime implements to downstream?

  Shifting the responsibility of runtime implement to user seems overwhelming. But most of time, we don't need a elaborated or luxury runtime like tokio or async-std, or in embedded development, there is no such an runtime for us, this is where crossbus make a difference, some lite executor like futures-executor, async-executor etc also work for crossbus. Moreover, in practice, it doesn't change the way you use runtime! On the contrary, offers more choices and more freedom to the user with cost of some line of code.

  you don't touch runtime when you build a wasm app, good, just use crossbus directly and don't do that neither. you like third-party's runtime like tokio, okay, just build and pass it before run crossbus. you use it in a lower level or a less compatible environment/ device where there is no runtime available. fine, use futures-executor or its fine-tuned version will do.

  Last but not least, even a bare-bone noop-waker executor can do.

• Is crossbus a completeness implement of actor model

  the short answer is almost but not complete. Crossbus implement almost all features. when an actor gets started, it can make local decisions, create more actors, send more messages, and determine how to respond to the next message received. some known incompleteness, so far, is runtime isolation. crossbus assumes user use a global runtime which specified by user to execute tasks when all business logic set up.

• how to explicitly handle asynchronous task with crossbus

  suppose you wanna run an async function:

  
  #![allow(unused)]
  fn main() {
  async fn run() {
  	// do stuff here
  }
  }
  

  you can

  • convert it into actor future with Localizer then spawn it with Context::spawn
  • or more directly, use Context::send_future

  for a more general type like Stream, Message Stream, Delayed Timer/ Message or Blocking wait message, crossbus has native support for them, you can just follow the document or see the integration tests as a reference

lastly, have a good time and enjoy crossbus!

Application

Some Possible Application and Demos of CrossBus in:

• Operating System Development:
  • Integrate blog os with crossbus vga text

Integrate Blog OS with CrossBus VGA Text

The Blog OS is a great series of source to create a small operating system in rust language.

And CrossBus is a lower level actor computing model compatible with bare metal, can efficiently and asynchronously transmit / share data between components which may make a difference in OS development.

Integration Target

Only the first 3 posts (by Vga-text) will be touched in the section. So if you don't familiar with post-1 or post-2 you'd better take a look beforehand.

Pre-Requisites

Since crossbus use rust alloc crate,

• we must add alloc to the build-std field of .cargo/config.toml:

build-std = ["core", "compiler_builtins", "alloc"]

• mark the global allocator
  • add emballoc to your dependencies
  • specified the global_allocator: ``

    
    #![allow(unused)]
    fn main() {
       #[global_allocator]
       static ALLOCATOR: emballoc::Allocator<4096> = emballoc::Allocator::new();
    }
    

Overview of Actor's Life Cycle

Here represents a simple illustration :

actor::create --> ActorRegister --> push to global static Register --> dropped when closed

Changes

• Switch to static Register instead of lazy_static / spinlocks

recall that the blog os defines a glocal Writer with lazy_static and guarded with spin::Mutex

#![allow(unused)]
fn main() {
lazy_static! {
    pub static ref WRITER: Mutex<Writer> = Mutex::new(Writer {
        column_position: 0,
        color_code: ColorCode::new(Color::Yellow, Color::Black),
        buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
    });
}
}

with crossbus, you

• don't have to worry about static / lock, or some stuff like that;

• access any type implemented trait Actor with global static mutable/sharing reference;

Details

So the dependencies spin or lazy_static is not necessary here:

#![allow(unused)]
fn main() {
// define the message
pub struct Msg(String);

// impl the Message trait
impl message::Message for Msg {}

impl Actor for Writer {
    type Message = Msg;

		// normally create the Writer
    fn create(_: &mut Context<Self>) -> Self {
        Writer {
            column_position: 0,
            color_code: ColorCode::new(Color::Yellow, Color::Black),
            buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
        }
    }

    // this line is not necessary though
    // a syntax must
    //
    // since we dont use an writer instance then
    // call this method
    fn action(&mut self, _: Self::Message, _: &mut Context<Self>) {}
}
}

According to the illustration above, once the actor is created, you can access it as glocal static item, and downcast it to the original type Writer, and you don't manually lock the Writer ( crossbus has assure its exclusively access)

#![allow(unused)]
fn main() {
// mark the writer's actor id
// used to get writer from `crossbus::Register`
static WRITERID: AtomicUsize = AtomicUsize::new(0);

// if Writer is not created
// then create one
if WRITERID.load(Ordering::Acquire) == 0 {
		let (_, id) = Writer::start();
		WRITERID.store(id, Ordering::Release);
}

// find the actor by id and
Register::get(WRITERID.load(Ordering::Acquire))
		.unwrap()
		// downcast the actor as mutable reference of Writer
		.downcast_mut::<Writer, _>(
				// here pass a closure,
				// writer is a mutable reference
				|writer: &mut Writer| {
						// and use it write string to display
						writer.write_fmt(args).unwrap();
						Ok(())
				},
		);
}

Results

go the project directory and use cargo run, you will see:

Code

this is the a section of integrating blog os with crossbus, the full code is at here