[openbeosstorage] Re: ddm questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 25 Oct 2003 02:40:52 +0200 CEST
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 :-)
> > 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 :-)
I don't think we should have it either, because I almost can't think of
a good reason to use it.
> 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, I wouldn't have seen it if you
hadn't used user_strcpy() :-)
> > > + 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 ;)
Bye,
Axel.
- Follow-Ups:
- [openbeosstorage] Re: ddm questions
- From: Tyler Dauwalder
- References:
- [openbeosstorage] Re: ddm questions
- From: Tyler Dauwalder
Other related posts:
- » [openbeosstorage] ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- » [openbeosstorage] Re: ddm questions
- [openbeosstorage] Re: ddm questions
- From: Tyler Dauwalder
- [openbeosstorage] Re: ddm questions
- From: Tyler Dauwalder