Re: Kernelland Draft Headers

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> On Mon, 09 Jun 2003 18:49:55 +0200 CEST "Axel Dörfler" <axeld@pinc-
> software.de> wrote:
> 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. :-)

Okay, cool. But right now, you could define another file system name in 
fs_read_fs_stat() (if you feel like it :).

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

Definitely! BTW the Media Kit uses "short_name" vs. "pretty_name"; but 
I think Name() would be okay. I have no real feelings towards 
DescriptiveName() vs. PrettyName(), but I think consistency would be 
great - but of course, descriptive_name could already be used, too - I 
have just not checked :-)

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

So you would welcome a change like this?
We will also make drivers modules with the new driver API (optional, of 
course), so that would just be another step to a more consistent 
concept.

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

Thanks!

Adios...
   Axel.