FreeLists / openbeosstorage / [openbeosstorage] Re: Kernelland Draft Headers

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Sun, 08 Jun 2003 21:42:38 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
> 
> On 2003-06-07 at 10:14:10 [-0700], Ingo Weinhold wrote:
[...]
> > Ah, wait a second. I may have confused myself. :-) 
> > BPartition::Type()/
> > ContentType() returns a type defined in DiskDeviceTypes.h, and
> > BDiskSystem::Name() certainly does as well. So, KDiskSystem::Name()
> > would be for kernel-internal use only, while only
> > KDiskSystem::DescriptiveName() (I'd prefer that one) is passed to 
> > the
> > userland API.
> > 
> > Does that sound OK, or do we want to have the internal name 
> > available
> > in the userland API as well? If we don't, I already hear the 
> > command
> > line fans shouting, because they would need to pass `BFS 
> > Filesystem'
> > instead of `bfs' to mkfs.
> 
> That's a tough call... You're right that the DiskDeviceTypes.h names 
> are going to be no fun to type... I guess it'd be all right to have 
> them both. But do we want Name() + DescriptiveName() or ShortName() +
>  
> Name() or ModuleName() + Name(), or...?

I vote for ShortName() + Name().
Do we also want to add BPartition::Short[Content]Type()? If not, which 
type is returned?

[...]
> > > KDiskDeviceJob.h
> > > ----------------
[...]
> > On the other hand, a SetDescription()/Description() combination can 
> > be
> > implemented in the base class, while a virtual GetDescription() 
> > would
> > need to be added to each subclass. Moreover I think the job 
> > description
> > shouldn't change after the job is constructed and it may even be, 
> > that
> > the information to compose the description is not longer available
> > after the respective shadow partition has been destroyed.
> 
> Sounds like SetDescription()/Description() it is. Although, one could 
> argue for eliminating SetDescription() and moving the parameter into 
> the constructor, particularly since we're already generating a fresh 
> id 
> then anyway.

Just let's call this an implementation detail and decide spontaneously 
when implementing the classes. :-)

> > 
> > > Maybe a
> > > KDiskDeviceJob::GetInfo(user_disk_device_job_info*) would be 
> > > handy?
> > 
> > Certainly not a bad idea. :-)
> 
> Let's add it then. :-)

It's in.

> > > (3) Agreed. :-)
> > > 
> > > (4) This is kind what I invisioned the extra progress info 
> > > updates
> > > being used for, but perhaps more simply so, i.e. a way to notify 
> > > the
> > > user at what stage of a given task the process was at.
> > 
> > Well, there shouldn't be a problem to use the extra progress info 
> > for
> > that.
> > 
> > > We could also
> > > add progress updates per subtask, I suppose, to allow two status 
> > > bars
> > > to be shown. Is this what you're thinking?
> > 
> > Something like this. What I don't find so nice, if we have only a
> > progress value for the complete task, is that the subtasks may be 
> > very
> > differently fast. E.g. for resizing a partition, where setting the 
> > new
> > partition will probably be very quick, while resizing the FS may 
> > take
> > quite some time. So, if a simple progress bar is shown, it appears 
> > like
> > half the progress is made in a second, whereas the other half takes 
> > an
> > hour.
> > 
> > It may be nice to have a more a more detailed progress info, like a
> > BDiskDeviceJob::GetProgressInfo(disk_devive_progress_info *info) 
> > with:
> > 
> > struct disk_device_progress_info {
> >     int32    subtask_count;
> >     int32    done_subtasks;
> 
> How about "completed_subtasks"? That sounds better to me, even though 
> it's a little longer.

Yes, sounds better. :-)

> >     float    current_subtask_progress;
> >     char    current_subtask_description[256];
> > };
> 
> Okay, that's probably a good idea. Let's do that.

Almost done. :-)

[...]

CU, Ingo