[openbeosstorage] Re: Kernelland Draft Headers

On Mon, 09 Jun 2003 18:49:55 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > 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.
> 
> Just a second: currently, file systems are not handled like modules -
>  
> that is, they will be accessed by name, not by any other strange 
> information :-)
> For clarity, transparency, and consistency I would like to keep it 
> that 
> way for the "mkfs" command - because the file name is the only thing 
> you see of the file system, you cannot know if it's internal short 
> name 
> is "bfs", "barfs", or even "smurfs".
> That will also make the kernel implementation easier and more 
> straight-
> forward :-)

The point is, that the `internal' short name is the file (or module) 
name -- as opposed to the one, that was planned until now, which should 
be more user friendly. That's the reason, why we want to make it 
available in the userland API, too. :-)

Mmh, maybe Name() + DescriptiveName() is better than ShortName() + 
Name(), after all. Grr, naming is always the most complicated part. ;-)

> If we are about to change the access pattern to file systems in a way 
> like this, I would rather get rid of that special architecture and 
> make 
> them modules, like (almost) everything else.
> Then, bfs could have a module name "fs/bfs/v1" or whatever :-)

Sounds good.

> Still, it would be great if it could be accessed by file name from 
> userland. It would also be nice to have the module names in an 
> attribute for the Tracker, and/or a utility which prints out the 
> module 
> name of a given file (yeah, I know, not really related :).

Well, why not.

> > > (1) I think that makes sense.
> > It's gone.
> 
> What a nice flow of discussion ;-)

:-)

> > 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;
> >     float   current_subtask_progress;
> >     char    current_subtask_description[256];
> > };
> 
> While I like the idea of having the ability to monitor subtask 
> progress 
> (and I agree with completed_subtasks :-)), why shouldn't we just call 
> them tasks, and task progress? I thought the "job" could comprise 
> several independent tasks.

Good point. Consider it changed.

CU, Ingo

Other related posts: