Hi. I'm in the process of designing a microkernel OS, and I was wondering what the general approach to opening/closing/utilising files is - how do i tell the filesystem daemon what file name I want? should messages be of variable length so I can send the whole string at once, or should I say "the next xx messages I send make up the file name", then send the string one part at a time? when reading/writing to a file, should I use a piece of memory that both my app and the filesystem daemon have access to, mess with the raw data in the file, and tell it to save when I like? or should I ask it for each indvidual byte/word of the file via messages?
I think at first I might just do everything with messages, not buffers, as it would be easier, and i'm just trying to learn, not make a fast useful OS.

Thanks in advance, Compilax.

You forgot third type of kernel in your poll - exokernel.

what is an exokernel? i know it's like microkernel but taken further, but is there any actual definition? I thought it might be if things like memory manager are outside the kernel, but many OSs that do this (Minix for example) are refered to as microkernel... i'll add anyway. examples?

*EDIT* Uh-oh i can't change the poll options... sorry.

What you are thinking about is the whole messaging strategy of your os, not just filesystem. Passing string data in stack is difficult because you can't do 1 byte pops, and equally insane to try to use registers for that too.

So memory, how? You could pass the address in a register or stack for an asciiz filename, through a scratch area in the calling program provided the os has read permissions for this area. This could be the easiest way.

Or, if you choose to use the hardware multitasking mechanism, you could even set up a separate segment for communication with permissions explicitly given only to the calling program and the os.

Now this is still very easy when the communication is one way only to one external service/program, as the calling program can control the communication area. But what about when there's data coming back too? A separate data-back segment? And what happens when the program is calling multiple os services, some of which may take time to execute, so will you have a separate communication area for every service/program you call? It's about the levels of separation and protection.

These are tough questions without 'right' answers. Start small and build from that. It's all about how you choose to do it. I suggest you try to find your own way and experiment instead of doing things the same way others have done. Innovation is the mother of all fun

I've been thinking about these things too, I got a hardware multitasking mechanism which runs separate tasks (finally bug free and reliable yeehaa), but haven't gotten to creating a proper filesystem or anything else partly because I haven't been able to decide on comm strategy.

Well maybe when the winter comes...

SOLid Monolithic: eg SolOS

Exokernels provide no abstractions but allow the use of libraries to provide more functionality via direct or nearly direct access to hardware. In reality they do little more than multiplex the hardware. All normal OS services take place at the application level. Try reading http://c2.com/cgi/wiki?ExoKernel for a more detailed explaination.

kake_zinger: you can push/pop bytes... 4 at a time I was thinking of a stack for IPC, but not the normal stack - you use a kernel interrupt to tell the kernel to send app xxx a message, then it adds it to that app's IPC stack, then the recieving app checks its messages, and asks the kernel to get a message from the stack. when a message is popped, it should be the first message pushed, rather than the last as with the normal stack, so that it recieves messages in the order they were sent.
data coming back would simply be sent to the original process as with a normal message. maybe having a thread/conversation number on every message, so the original app would know that the message it recieved was intended as a reply?

Would having sorta like a DNS (as in domain name server like on the net) process - an app sends it a file name, and it sends back the PID of the file's owner (ie the process that has mounted that area), then the app can discuss opening/using/deleting/creating/etc. the file directly with that app, as opposed to having a VFS layer and sending all such requests through it - be a good idea?

P.S.: Exokernels seem ugly

They're no uglier than Microkernels

(about message passing)

Compilax: message queues wouldn't use a stack - you want a queue, thus a FIFO (at least if you want any kind of synchronization/serialization of messages). (That's what you already said though, so this is just some 'standard definitions' pedantry - bear over with me ).

Depending on what kind of OS being designed (ie, embedded system vs. something with users and network-connected), I would include (at least) timestamp (perhaps and/or msg-id), process-from, process-to - and perhaps even thread-{from,to}. And these would of course be "unforgable", even if a mechanism like windows "CBT hooks" was introduced to the OS. Why? To make sure an application can pass messages to itself and *verify* that these messages weren't injected.

Might seem paranoid/overkill, but if I was writing a consumer OS I'd be a bit paranoid - and ever more paranoid if writing a server OS. Everything depens on your goals though

Oh yes, I would buffer messages (to some extent), to avoid *having* to block after each send/recv message.

There's also some other things to consider - do you want stateless messaging (like windows messages), or "stateful" like pipes, or both? Which code parts and structures can be reused? Avoid duplicate code and structures if not necessary...

I agree.

--
BTW, If someone wants microkernel, Just try GNU HURD, or stick with MS-windows.

MS-Windows is not a microkernel and never was. WindowsNT is marketed as "modified microkernel" from Microsoft, but in fact it is modular monolithic kernel.

And GNU HURD is not the best example of microkernels IMHO. BeOS and QNX has a lot more features. (and actually microkernel is Mach, HURD is servers running on top of Mach, like MacOS X runs FreeBSD as server on top of Mach).

AISB, i think u-kernel is not better than m-kernel.

It didn't mean that u-k is technically not better than m-k, but, policy and design philosophy.

Edit: MS-windows is not u-k!?
Oh yeah, Please teach them to correct it, not me.
http://dmoz.org/Computers/Software/Operating_Systems/Microkernel/

correction:
MS-windows98 is m-m-k.
MS-windowsNT/2000/xp/2003 is u-k.
http://wiki.linuxquestions.org/wiki/OS

--
BTW, real u-k is L4Ka

Wikipedia:



Windows NT Architecture:



I don't think this could be called microkernel design.