Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosstorage] || [Date Prev] [06-2003 Date Index] [Date Next] || [Thread Prev] [06-2003 Thread Index] [Thread Next]

[openbeosstorage] Re: Kernelland Draft Headers

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Mon, 09 Jun 2003 18:49:55 +0200 CEST
"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 :-)

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 :-)

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 :).

> > (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.

Adios...
   Axel.






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.