Re: Some libl4 patches

[Marcus Brinkmann]

At Thu, 06 Jan 2005 22:24:09 +0100,
Matthieu Lemerre <address@hidden> wrote:
> > Next, please supply a change log entry.  For an example of a change
> > log entry, look in the ChangeLog files and in the GNU Coding
> > Standards.  It is important that this is included.
> 
> Should I provide it in the patch or in a separate file (tell me what's
> easier for you)

You can prepend it to the patch, but not as part of the patch itself
(ie, not in diff format), because changelogs often fail to apply
(whenever there was another change inbetween).
 
> >> in ia32/vregs.h: There was some problem with Buffer register
> >> loading/storing (basically, it didn't worked because the data were
> >> processed backward)
> >
> > Yes.  The same problem exists in the powerpc port.
> >  
> 
> Do you want me to include it in the patch too?

Yes, please.
 
> > So, you would have to check the first word of the string item.  This
> > is still flawed, but in a more subtle way, as even a string buffer of
> > length 0 is valid!  And thus you could not differentiate between no
> > string buffer items (buffer[0] == 0) and a single simple string buffer
> > item of length 0.
> 
> When I read the reference manual, I thought that:
>  -For simple strings: even if the length is 0, you have to provide a pointer

The pointer can be 0.

>  -For compound strings: as it is j-1 that is stored in the length word, 
> (where j is the number of substring pointers), we are obliged to have j>1

j is the number of subsequent string pointer words, which is >= 2 for
compount strings, but the field in the string item is j-1, this means
that it is != 0 for compound strings (and it is zero for simple strings).

> So in both case buffer[1] would be erased and we could for instance
> check if string_item->stringptr is nil.

The string pointer is not usable for any differentiation, as every
value is valid, including 0, and we can't get any information about
the presence and type of string items out of it.

Of course if you had the idea that 0 is not a valid pointer, then
things work out a bit differently, but that is never the case for any
L4 interfaces: In L4 0 is a normal address just like any other.

 
> > It would be very worthwhile to write test cases for all these
> > functions, that test for the silly border cases like adding a single
> > empty string item etc.
> >  
> 
> I could, but functions like store_brs don't have sense if not run on a
> thread on top of l4...

Well, one could define a special macro symbol that calls a function
instead of reading a register to get the address of the UTCB.  This
function could then be provided by the test environment and point to a
malloc'ed area.  In addition, a fake kernel interface page and system
call stubs could be provided by the test environment (you would need
another macro symbol trick to replace the lock nop system call of
course, and similar hacks).  Then you could basically emulate L4
system calls, and check in the system calls that the right parameters
have been passed in the right registers.

But actually, just testing the pure user-space functions for composing
messages etc would be quite good already.

> So should I write test cases that would be "embedded" in a server?
> If so, I will maybe provide a separate test file. (I already test my
> patch with some printfs in bucket-manage-mt())

No, I was thinking about stand alone tests which just check individual
libl4 functions.
 
> BTW, When in physmem, I manage to receive string items from deva, but
> propagating the message to the worker thread seems to block when doing
> the call. If you have a clue... otherwise I'll try to find out.

When propagating a message with string items, you have to keep in mind
that string items also have to be propagated, ie copied into the
worker thread's string item buffer.

Every worker thread needs its own string item buffers.

Theoretically you could frob the message and manage multiple string
item buffers in the manager thread.  But it is unclear if the overhead
of that is more or less than just copying the strings.  Depends a lot
on usage patterns and such.

Thanks a lot,
Marcus