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