Re: Kernelland Draft Headers

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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.