[openbeosstorage] Re: ddm questions

On 2003-10-24 at 17:40:52 [-0700], you wrote:
> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > > You have to copy all pointer references from userland applications
> > > using the provided user_*() copy calls. The reason is simple: there
> > > is
> > > no guarantee that this memory stays valid during the execution. So
> > > if
> > > any kernel function has to access the memory the pointer points to,
> > > you
> > > need to copy it first into kernel space to make sure it stays
> > > valid.
> > Yes, but I was asking about copying back out (i.e. what the intended
> > semantics of the functions are).
> 
> I know, that paragraph did only prepare the points I listed later on -
> the way I did it was probably confusing, so I am sorry about that :-)

Comprendo. :-)

> > > But there are some problems in your code:
> > > - there is apparently no user_strcpy() function in the kernel - you
> > > could either implement it (by calling user_memcpy()), or just call
> > > user_memcpy() directly - which is the preferred way, if you already
> > > know the length
> > Isn't there one declared in headers/private/kernel/vm.h right next to
> > user_strlcpy() and friends, and defined similarly in
> > src/kernel/core/arch/x86/arch_cpu.h, etc?
> 
> Yeah, it's just not implemented anywhere :-)

What about in src/kernel/core/arch/x86/arch_cpu.c ? Isn't that an 
implementation?

> I don't think we should have it either, because I almost can't think of
> a good reason to use it.

Fair enough.

> > That would be fine with me (adding a buffer length parameter). Ingo?
> 
> It would be needed for the syscall only anyway.
> 
> > > - you only check the return value of user_strlcpy() for >= max.
> > > name
> > > length - that's not correct; you also have to check it against
> > > values <
> > >  B_OK - that's what it returns to report an error
> > Damn. Another good point. Thanks.
> 
> Since I somehow never got the CVS diffs, 

Neither did I, for some reason...

> I wouldn't have seen it if you
> hadn't used user_strcpy() :-)

Now I'm confused. Is/was something not building for you because of the 
user_strcpy() calls? I seem to have no problem with it over here. And 
further, I can't see how it's any more unimplemented than user_strlcpy() or 
user_strncpy(); there seems to be corresponding code for user_strcpy() 
everywhere there's code for those two functions (unless I'm missing 
something, which wouldn't be a first ;-). 

> > > > + Do we have a limit on the length of those parameter strings?
> > > > I'm
> > > > currently assuming no.
> > > I don't think there is a limit. However, to be more robust, we
> > > should
> > > introduce one, 32K or 64K.
> > Take your pick. :-)
> 
> Oh no, so everyone will point their fingers to me if it turns out that
> it is not enough ;)

Exactly. ;-) :-)

-Tyler

Other related posts: