The order of the object files specfied in the linking command DOES
matter. /home/disy/l4/lib/crt[0S].o must be first on the line,
followed by your object files, then followed by -lc (libc.a) and
-ll4 (libl4.a).
[97-10-16]
It fails as those tasks are already running and you are not the
chief of them. Task 0 is the nil id, task 1 is sigma zero, task 3 is the
serial port server, and task 4 is likely to be SOS in your case.
[97-10-15]
The above is an artifact of the combination of a 32-bit compiler
generating code for a 64-bit address space together with sign
extention. A detailed description exactly what happens is beyond the
scope of this FAQ. Simply ensure all data references (stack included)
are BELOW 0x70000000 and you will stay out of
trouble.
[97-10-15]
The choice is up to you, however you must be able to support at
least 32 simultaneous tasks.
[97-10-08]
dit currently only supports data files greater than 15
bytes in size. Simply pad your file with extra bytes to work around the
problem.
[97-10-08]
Up to you, a matter of how you want to structure things. It's probably easier to have the client only have to deal with a single OS server (and maybe better software engineering as it hides the OS implementation details.)
There is also no inherent need why there need to be different
OS servers for different system calls in the first place - one
can handle all system calls (although there are some advantages
to having multiple servers). You need, of course, several
threads (e.g. one pager, one keyboard reader, one exception
handler (although that could be combined with the
pager)). Whether you use more than that is up to you.
[97-09-18]
You cannot get this from any environment variable, nor from a global variable - after all, your client runs in its own address space (think about what this means).
The best way to find out whom to talk to is to wait for an IPC message. The OS, after starting a task, needs to send it a ``wakeup call'', from which the client finds the ID of the OS server.
There is another way to do it: you OS could initialise some
data in the first page mapped to the client's stack, and it
could find out from there. However, the IPC way is much
easier. Check the supplied sample
code.
[97-09-18]
Sorry, we forgot to include dit.h in the hardcopy
manual. You can find it in the include
directory.
[97-09-15]
You are trying to use floating point, which is not supported in your version of the kernel.
As a general rule, don't use floating point in OS code.
[97-09-15]
Check the L4
Reference Manual (Section 2.7) and the pager example.
[97-09-15]
Read up your third year OS text.
[97-09-15]
This was really answered in class, but...
You reserve a sufficient number of frames for you OS data
structures (remember to mark them as used in your frame table later
on, or to not keep them in your frame table in the first
place). Assume your frame table is an array of base type
frame_t (a struct, of course). You assign to a variable
(say ft_base)
the (physical) base address of these frames. When casting this to
frame_t* the resulting pointer can then be simply
de-referenced, e.g. ((frame_t*)ft_base)[frameno].pageno
will give you field pageno of frame frameno.
[97-09-15]
Run
For more details:
It means that the page fault happens during a system call, when L4
tries to access user data (e.g. during a long IPC operation). You
probably have a string dope pointing to the wrong place.
[97-09-10]
It means that you are trying to access kernel-reserved memory. The most likely reasons for this are:
To eliminate these error messages, make certain that all pointers are properly initialised. Use assert(p) if in doubt.
Also make sure you are not overflowing your stack. It is safest not
to put arrays or large records on the stack, declare them as
static. Note that you can use the static storage
class also for a function's local variables, that way you do not
lose the locality local variables give you. However, be aware that
you may have to use concurrency control on local static variables
if the function can be called from different threads.
[97-09-09]
It means that the address of the message header, divided by four, is stored. Of course, dviding by four just means chopping off the two least significant bits, which leaves 62. This is just a way of saying that only the leading 62 bits of the address are stored. Which is fair enough, as the message descriptor must be word (i.e. 8-bit) aligned, which ensures that the three least significant bits of the address are zero and do not need to be specified. L4 makes use of this to use those bits for the m (mapping) and d (deceiving) flags.
You actually don't need to worry about this, as you're using the C library interface. That one automatically masks in the d bit if you are using a deceiving version of the system call interface, you just pass the message header address to that function.
How the m-flag gets set can be seen in the pager example.
[97-08-27]
No. The serial port driver will output data passed the registers
until it encounteres a null byte or has processed all data. Hence
if you want to send a string of 64 bytes you can do this in a
single call.
[97-08-27]
Unfortunately the serial port on the DECstations turns out to be really crappy, it drops packets when it cannot keep up. Things tend to be worse when there is other activity on the machine (like moving the mouse, running a compilation).
Best to keep TTY output short and well separated. Consider putting
a delay into you ttyout_server after each package.
[97-08-24]
void *rcv_msg is an input, not an output parameter to the system call. It passes to L4 a message descriptor which describes where to store the IPC message. L4 expects that parameter to point to a properly set up message header (followed by appropriate buffer space and string dopes).
The only output parameters in the IPC system call(s) are
rcv_reg, which points to a buffer receiving the
in-register part of the message, and result which returns
the result status and the number of words of in-line data and
strings delivered in the message.
[97-08-23]
There exists, as yet, no L4 User's Manual. The most definite reference is the L4 Reference Manual, however, this does not explain everything you need to use L4. We are working on improving the reference manual, and also on a user's manual.
The C interace to L4 is documented in a set of UNIX manual pages. It is also worthwhile looking at the header files defining the C interface to L4.
More general information on L4 can be obtained from a number of technical publications, in particular