Hello,

The long journey of developing components for L4Re continues - a story for 
another time, perhaps - and I have been testing code that works with the old 
Subversion-based L4Re distribution on the newer Git-based L4Re distribution.

One thing that seems to be different between the old and the new is when a 
call like the following is performed:

l4re_rm_attach(addr, size, L4RE_RM_SEARCH_ADDR, ds, offset, L4_PAGESHIFT);

Apart from L4RE_RM_SEARCH_ADDR seemingly being replaced by a differently-named 
constant, L4RE_RM_F_SEARCH_ADDR, it appears that such a value for the flags is 
insufficient and that additional rights flags might be required.

If I omit such rights flags, I get the L4_ENOENT error value, but this worked 
before. So, I think I may have misunderstood the behaviour of the function. Or 
are there now additional constraints imposed by the region manager that 
prevent any inappropriate accesses from bothering the dataspace? (My dataspace 
does test the flags on map requests against the rights supported by the 
dataspace itself.)

Another difference that I see between the old and the new is in the flags used 
for map requests sent to dataspaces. In the old distribution, there were these 
definitions (in pkg/l4re-core/l4re_c/include/dataspace.h):

  L4RE_DS_MAP_FLAG_RO = 0,
  L4RE_DS_MAP_FLAG_RW = 1,

It appears that map requests now use the following:

  L4RE_DS_F_R   = L4_FPAGE_RO,
  L4RE_DS_F_W   = L4_FPAGE_W,
  L4RE_DS_F_X   = L4_FPAGE_X,
  L4RE_DS_F_RW  = L4_FPAGE_RW,
  L4RE_DS_F_RX  = L4_FPAGE_RX,
  L4RE_DS_F_RWX = L4_FPAGE_RWX,

I think the actual values involved here are different, but I imagine that 
since everything should be manipulating values derived from these definitions 
(as opposed to maintaining separate definitions of the flags), no 
incompatibility would normally be observed. But the apparent lack of 
conservatism surprised me slightly.

Anyway, if anyone has any insight into why the attach operation behaviour is 
different, I would very much appreciate it!

Paul



_______________________________________________
l4-hackers mailing list
[email protected]
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Reply via email to