Re: user_memcpy()

"François Revol" <[email protected]> wrote:
> > Doing is_valid_range() correctly is quite a bit overhead, and if 
> > possible I would like to get away without doing that :-)
> > I think we could introduce something like:
> > 	bool called_from_kernel(void);
> Whatever the name.

I actually care a lot about names ;-)

> > The VFS could set a flag in the current thread structure. For 
> > Haiku, 
> > we 
> Yes that was my idea.

Okay then, let's do that.

> > could also easily change the driver API (which we do anyway for new
> > -
> > style drivers), but a common solution would be preferable, I guess.
> We already have the new driver model in as we need it for the IDE 
> replacement driver.

I'm afraid they won't be compatible. Thomas' is (partially) pretty much 
a hack to get it going on top of R5, in our version all of that stuff 
is gone, and it's partially very different, too.
If Zeta uses the messy version for now, okay, but please don't make it 
the public driver API already, or you'll certainly regret it.

> > > #define B_READ_AREA 1
> > > #define B_WRITE_AREA 2 */
> > > #define B_USER_READ_AREA    0x00000004  /* user can read */
> > > #define B_USER_WRITE_AREA    0x00000008  /* user can write */
> > Isn't it the other way around?
> > B_READ_AREA already expresses "user can read". What's missing is a 
> > B_KERNEL_READ_AREA (meaning: only kernel can read if used alone).
> Nono.. actually it's not the same values... the real constants are:
> inc/vm.h:#define PROT_KRD       0x00000001      /* kernel read */
> inc/vm.h:#define PROT_KWR       0x00000002      /* kernel write */
> inc/vm.h:#define        PROT_URD        0x00000004      /* user read 
> */
> inc/vm.h:#define        PROT_UWR        0x00000008      /* user write 
> *
> /
> inc/vm.h:#define        PROT_ALL        (PROT_KRD | PROT_KWR | 
> PROT_URD 
> | PROT_UWR)

Ah, okay, I got you now.

> > I don't think it should be always root, even if it could simply 
> > switch its access rights if needed (which would only be safe, 
> > though, if these rights could be specified by thread).
> But they aren't. uid/gid is set for a whole team.
> of course getuid() and friends could use called_from_kernel()...
> But that would hide the real uid, so if someone really wants it...

Well, I don't think the kernel should be always root - but there might 
be a need for being able to safely switch the user ID. Anyway, I didn't 
yet come across such a situation, and until I do, I don't see the 
urgent need to introduce something for this.

> > Why FD?
> cause it depends on if the call is made on the user fds or the kernel 
> ones.

Okay, but I really think a called_from_kernel() or called_from_user() 
is sufficient.
User FDs should be handled in the same way when used in the kernel as 
they are in userland.

> > Anyway, I think we should have those two:
> > bool called_from_kernel(void);
> > bool is_user_address(void);
> I'd go for those... hmm is_ usually means it applies to a passed 
> argument.
> do_check_user_address maybe ?

Damn, of course, I meant:
	bool is_user_address(void *address);

Although I wonder how a do_check_user_address() could work without an 
argument?

> > (or also called_from_user() instead)
> That one would just be !called_from_kernel(), which is conceptually 
> different than the address stuff. (it's basically or R5 because 
> though 
> we must supposed we are called from user we must not check for user 
> addresses).

called_from_user() would be the same as called_from_kernel() - it's 
different from the address stuff, but since they are commonly used as a 
pair like in:
	if (called_from_kernel()) {
		// trust the kernel, as it does deserve the right to destroy 
itself
		memcpy(...);
		return B_OK;
	} else if (is_user_address(buffer)) {
		return memcpy_to_user(buffer, ...);
	} else
		return B_BAD_ADDRESS;

I thought it would be nice to have them consistent, but maybe it's even 
fine this way :-)

> > > I think I can stick something in Zeta R1, but the time window is 
> > > shrinking, so it would be nice to reach a consensus there...
> > Would be nice, yes, although I we will definitely introduce a new 
> > driver architecture, anyway, so maybe the pressure to be compatible 
> > is not that high (even if we both could benefit from it).
> One more ?

Hopefully just one (the reworked version from Thomas) :-)
But if we won't like what I did to it (I am in the process of doing so, 
actually), we may want to introduce just another one :))

> Remember it's yT's prerogative to increment B_CUR_DRIVER_API_VERSION 
> now :D

Please feel free to do so, we won't have that anyway anymore :-)

Bye,
   Axel.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r