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

|