Hi,
> In fact, it gets time to think about how to implement a "hardware
> abstraction" concerning the devices.
How much would we like to get inspired by Linux Kernel (not just in this area)?
> I mean, we must, in some way, manage all devices which are present to
> the system.
> We (the kernel) will only be responsible for recognizing that there are
> some devices and to provide some sort of infrastructure, that allows
> only one process (-tree) to use the specific device.
> What's done with the device is then up to the driver, which should not
> be part of the kernel and thus exchangeable.
What sort of user-space application interface would we like to provide?
Unix/POSIX? We will need to design and implement system calls.
The ABI is much related to this, since we probably do not want
to write our own libc implementation.
How much modular would we like the kernel to be?
Presumably, we are doing a monolithic one.
We can have loadable kernel modules, and then maybe
user-space drivers (and filesystem implementations).
I do not yet see any usefull modularity beyond this one.
(well, unless we want to play with the ability to
switch to different scheduler (or whole kernel) at runtime,
which I do not know how much usefull it is, just random idea).
I get it that our goal is to be able to run user-space applications
(with support for dynamic libraries). This means choosing
compiler and stuff.
Then there is also networking (tcp/ip stack).
Anyway, are we going to port some existing source code (2),
or do everything from scratch ( yes! :-) ?
Now, in the forums, there is an idea to write an embedded OS.
This is interesting from, at least, two points:
- the embedded hardware might not have MMU
- organizing the kernel source code and managing a decent control over
the build process
I think I am interested in all of it, but primarily in loadable
kernel modules and user-space application execution
(since they both deal with ELF).
Tomas
|
