[openbeosstorage] Re: ddm questions
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 27 Oct 2003 20:02:27 +0100
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.
> > 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?
> > 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:
