Framework redesign?

[BarclayII]

After trying on MSIM I found my design... awful, as it's not very scalable.

I guess I'll change my framework some time after dynamic memory allocation implementation.

[davidgao]

please explain what is going wrong.

[BarclayII]

I'm not satisfied with current driver function implementation, which switches drivers by compiler macro switches, and therefore having an underlying assumption that there's only one input device, one output device, etc.

What I'm thinking is that our kernel framework should at some point support multiple input/output/storage devices. Even if our boxes have only one such device, our framework should allow multiple devices to plug themselves in.

I had sent you a tutorial PDF earlier in this holiday which somehow addressed this problem.

Of course redesigning involves much work, so I'm wondering whether it's essential to do so.

[davidgao]

We'd better work out the document right now. I opened a gitbook repository so that we can work on the forked version of xv6 together.

…

This redesigning can be done later.

[BarclayII]

Agree.

I've uploaded the device structure header to include/device.h.

Where's the gitbook stuff?

[davidgao]

https://www.gitbook.com/@davidgao/dashboard

contains two book, one as a fork of xv6-book and one as the lab document
connect to gitbooks and i'll give you collaborator access

[BarclayII]

Can't access your book: 403 Forbidden.

Strange...

[davidgao]

After looking things up, I have come to an idea:

1. We leave the drivers here AS IS, at this moment, so that we can use the devices before we come to memory management.
2. We deal with memory management properly.
3. We register devices and drivers dynamically, like we do in linux. This is what a modern OS should do.

Any ideas?

[BarclayII]

Totally agreed.

That's why I intended to reimplement driver framework after dealing with dynamic memory allocation