Re: [Open-beos-cvs]CVS: current/src/kernel/core/disk_device_manager ddm_userland_interface.cpp,1.17,1.18

On 2003-09-27 at 16:11:02 [+0200], Axel D=F6rfler wrote:
> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > I'm afraid, the cookie handling is not sufficient. At any rate
> > userland memory access should only happen through user_memcpy().
> > E.g. in user_get_next_port_info():
> >=20
> >     if ((addr)ucookie >=3D KERNEL_BASE && (addr)ucookie <=3D KERNEL_T=
OP)
> >         return ERR_VM_BAD_USER_MEMORY;
>=20
> We even have a handy macro for this:
> if (!CHECK_USER_ADDRESS(userCookie))
>     return B_BAD_ADDRESS;

Ah, right, I vaguely remember having seen this one before. :-)

> Please don't use the ERR_xxx style error codes anymore, they will be
> phased out until R1.

Sure, I was just too lazy to look up the right error code (though it's na=
me=20
is not really a surprise :-). ;-)

[...]
> > There are at least two solutions:
> >=20
> > 1) IIRC, Axel once mentioned, that one could lock userland memory
> > and wouldn't need to do the copying into kernel memory and
> > back, then. I don't remember what the status of this feature was.
> > Unimplemented?
>=20
> In the current VM, this is not implemented, right. But even BeOS does
> this, so we could do this, too (right now, there is no swap file, so
> nothing is paged out anyway). But of course, those pointers would only
> be valid in the current thread context, other kernel threads might not
> be able to access it.

That would be sufficient in this case.

> > 2) Relocate the pointers. It shouldn't be too hard to add the
> > required
> > relocation functionality to UserDataWriter and make the concerned
> > classes use it.
>=20
> That might be a good idea. Do we need to have pointers there, anyway?

Probably even `need'. For name, content name, type and content type of a=20
partition we could use fixed sized char arrays (though that would waste=20
quite a lot of memory), but parameters and content parameters have no siz=
e=20
restrictions. Offsets relative to the beginning of the buffer could be=20
used, but that would be quite inconvenient. The pointer solution is quite=
=20
OK, I think.

CU, Ingo