[openbeosstorage] Re: ddm questions

On 2003-10-27 at 11:02:27 [-0800], you wrote:
> 
> On 2003-10-27 at 02:55:32 [+0100], you wrote:
> > 
> > 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.
> 
> Exactly.

Good deal.

> > > 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.
> 
> You mean the ones defined in <DiskDeviceTypes.h>? The longest one already
> occupies 28 characters. Maybe it's better to have some more margin?

Yikes. Okay, maybe so. I'll switch those, too.

> > > 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. :-)
> 
> Cool. :-)
> 
> CU, Ingo

Other related posts: