[openbeosstorage] Re: ddm questions

  • From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Sun, 26 Oct 2003 17:55:32 -0800

On 2003-10-26 at 03:22:56 [-0800], you wrote:
> 
> On 2003-10-25 at 10:25:01 [+0200], you wrote:
> > > > > Yep, the non-const was chosen intentionally. I had the feeling, that
> > > > > e.g.
> > > > > truncating a name wouldn't be too unusual.
> > > > 
> > > > So do you not want me to return B_NAME_TOO_LONG if the name is larger
> > > > than
> > > > B_OS_NAME_LENGTH and instead let the validate function handle things?
> > > 
> > > That's what I was trying to say. :-) The string is passed to the disk
> > > system,
> > > which will truncate the name, if necessary, and the syscall just needs 
> > > to
> > > copy it back into userland space.
> > 
> > Are you okay with truncating it when copying from userland at the start of
> > the respective _kern_XYZ() function (but not returning an error if
> > truncation
> > occurs)? This is what I've done for the moment, as it seems more efficient
> > than arbitrarily allocating and copying the entire string and then forcing
> > the validate function to truncate it.
> 
> Ah, OK, sure, I misread you. It makes sense to enforce the B_OS_NAME_LENGTH
> limit already in the respective validate syscall. The disk system will
> truncate the name further though, if it has more restrictive constraints.

Okay, just to make sure we've got it all worked out here :-), we'll truncate 
the name at B_OS_NAME_LENGTH (or B_FILE_NAME_LENGTH, whichever we go with) at 
entry into the syscall. In these instances, we won't return an error on 
truncation. Furthermore, the disk system may make further modifications to 
the name, so we need to copy it back out at exit from the syscall. 

> BTW, do you think B_OS_NAME_LENGTH (32 chars) is sufficient for partition
> (content) names? 

That's where volume names end up getting stored, isn't it? No, I don't like 
the 32 character limit for the volume names. Seems okay for the disk-system 
type names, though.

> Since we don't use fixed size arrays in any structures, it
> would do any harm memory-wise to allow longer names. Oh, as I just realized
> fs_info reserves B_FILE_NAME_LENGTH space for the volume name. So we should
> probably use that limit too.

Oh good, let's definitely go with B_FILE_NAME_LENGTH for the the partiton 
[content] names, then. :-)

-Tyler

Other related posts: