Mark McKenna wrote:
> Hey there. I'm new to the list as of a few days ago, and I've been
> lurking for awhile to get a feel for the project. I've been racking my
> brains for months now to try to develop a new OS that improves
> fundamentally on those already existing, and I stumbled across you guys
> on sourceforge; it seems to me like you've got a wonderful thing going,
> and I'm really interested in knowing more.
> I'm not great with asm as things stand right now; I'm just reading docs,
> scanning instruction sets, and so on. Mostly, I just have ideas about
> things, and not necessarily right ideas, either :^)
> So, I was following this conversation about the ICS subsystem, and I was
> a) Can the OS be operated if the ICS cell isn't in place, or is it built
> in to each cell (or several cells) already?
> b) About not enforcing a certain message structure on the ICS channel;
> this seems like a great idea. But what if someone wants to impose a
> specification on a channel? Lets say there's some GL driver development
> going on, and it has to cover more than one type of card. If we bind a
> lingo to a GL channel, we can replace one driver with another on the
> fly; not only that, we can have people develop GL clients without having
> to know the specifics about the GL server. Yeah, this is a programmer's
> benefit, and I get the impression that you're trying to leave that to
> the docs; OTOH, when you're dealing with hardware, writing a bad
> instruction can send the system into seizures. Is the driver cell
> responsible on its own for checking bad messages? Can another driver be
> laid out over it to do the checking when desired, then opted out after
> its mostly stable? Is this a higher-level concern? Did I just answer
> my own question? I guess what I want to know is, can a cell be placed
> in such a way as to intercept and verify driver calls between a client
> cell and a manager cell?
> Hrm... guess that's it for now. Sorry if it doesn't make a lot of
> sense; I've never done anything like this before.
^ eheheh, typo? ;)
Actually, your concerns/questions do make a lot of sense. Being
able to actually use a intermediate level to check if the cells
behave properly is quite useful when building up the system and
testing it for bugs.
Fortunately for you, it can easily be done. By building a cell
that could verify the various parameters passed thru the channel,
and by calling that cell from the client at the reception of a
message, it can be possible to do. It's simply a matter of removing
the call from the client cell when you figure things are stable.
As for the specific format of a channel, we have built it so that
all the registers of the processors are left entirely free to the
sender and receivers to use. It is then possible for you guys to
pass on parameters via registers, and to decided that for example,
EAX is the time of day, while a guy building up another channel
decide that EAX is the number of files opened.
We have made sure while designing ICS to leave as much freedom
as possible to both sender and receiver.
As to know if this can be or not implement in the cell, it is a
personal choice of the cell developper to use ICS or not. There
are lots of advantages of using ICS, but it is possible to yet
build a complete cell, fully void compliant that do not use ICS
at all. So it would eventually be possible to have a set of cells
that could implement the whole void architecture without any
ICS function. But.. IMHO, that wouldn't be a good design. ICS
do have great advantages and provide very powerful mechanism to
be implemented easily, such as memory allocation tracking,
thread and node debugging, groups of applications all interacting
and cooperating together, etc.
As you have seen, we are starting slowly (or not so slowly) to
build our documentation base. Even if you are not actually
hyper proficient in assembly, it shouldn't be very hard for you
to catch on. Assembly is after all, the simplest language
somebody can find, and our programming environment makes it
quite easy to do some really powerful stuff.
Don't hesitate to ask any other question !