Re: New task list items on savannah

[Marcus Brinkmann]

On Wed, Jul 30, 2003 at 01:18:20AM +0200, Marco Gerards wrote:
> I've included some descriptions I wrote with this mail, I've also
> written a new task for fatfs. I just called this item "Fix writing
> support", which includes many small tasks. Is it better to divide this
> task in many small tasks? (I'll wait with adding this task/tasks
> before I add this task on savannah).

I think that each of those you listed is independent of the others, so they
should have their own task.

I am not going to comment on priorities and difficulties, I found it hard to
judge this.  I think those are best left to the person assigned to do the
task.  Fill them in with whatever your judgement on this is.

Another way to find tasks is to grep the source for XXX and FIXME comments.

> Fix writing support
> 
> priority: 7
> difficulty: 8
> 
> Writing support in fatfs does work a bit, but it is far from
> perfect. Before it correctly works these things should be fixed:

If you have one task for each of these, they are differently difficult and
prioritized.
 
> - Unsupported calls (like file_chown, file_chmod should be ignored (or
>   correctly handled, if that is possible).

Try to make a complete list before adding this task.  Group the list in
related functions - related by what the implementation in fatfs would be.
There might only be one group, or several.

Try to write whole sentences when adding the task.  Like:

"The following calls need to be overridden:

* file_chown, file_chgrp, file_chauthor: Setting the owner of a file
  is not supported.

* file_chmod: Only some [list which ones] Unix attributes are supported
  in fatfs.
"

etc.

> - Reimplement dir_rename_dir, the libdiskfs version relies on
>   hardlinks.

I think it makes sense to first describe what the purpose is, and then go
into the technical details.  Like:

"FATfs does not support renaming directories.  The implementation in
libdiskfs, dir_rename_dir, relies on hard links.  So this function needs to
be overridden and replaced with FATfs specific implementation."

One might also point out locking and serialization issues as far as you are
already aware of them.

> - Fix the locking problem in write_node (actually there are two).

You have to describe the locking problems in great detail to make this a
useful task item.  Always imagine that the reader is potentially clueful,
but unaware of any specific details.
 
> - When removing files gaps are created in the directory. Remove a
>   block when it is only filled with deleted files, perhaps move
>   directory entries to prevent a directory from eating diskspace.

This could be called "directory fragmentation" or so.

> - Check if a FAT32 partition was cleanly unmounted. fatfs should also
>   set this information.

Right.

> - The filenames are presented as they are on disk when reading. It is
>   better to convert them to uppercase/lowercase names. Always write
>   files in uppercase.

Ok.

Another one:

Use the information in the superblock to find out how much disk space is
used/free.  Update this information.
 
> -------------------------------------------------------------------------------
> 
> Write a utmp translator
> 
> priority: 4
> difficulty: 5
> 
> Design the utmp interfaces and write a translator. Change all programs
> that use utmp to use this translator.

I know you got this from the official task list, but I would only want to
see it in Savannah if you can roughly describe what this translator and the
interface should do.  Because the above is only going to raise more
questions about it, questions which I couldn't answer (maybe Thomas or
Roland can explain this task item).

In general, a task item should provide enough information to get people
started.  It should be clear what needs to be done in which way.  If it only
says what needs to be done without saying how (and the "how" is not
obvious), then the task item is only of limited usefulness: It can serve the
people who know how as a reminder, but that's it.

> (libnetfs)
> Support --readonly, --writable, and --update

Again, use whole sentences.

> priority: 5
> difficulty: 5
> 
> Libnetfs should handle these options just like libdiskfs does. It
> should be possible to get and change these options after the server
> started using fsysopts.

> (libdiskfs)
> Handle dead name notifications on execserver ports.

That's not at all important right now.  It's probably a somewhat obscure
robustness issue.

> priority: 6
> difficulty: 3
> 
> When the exec server dies it is impossibly to start a
> program. libdiskfs should handle dead name notifications to find out
> if the exec server died and alert the user.

You are sure that this is what it is about?  init already should do that.

> -------------------------------------------------------------------------------
> 
> Support multiple users per uid
> 
> priority: 5
> difficulty: 5
> 
> It is only possible for one user per uid to log in. The uid is passed
> to the password server instead of the username. The password
> (password.defs) interfaces should be changed so it is possible to pass
> the username to the password server.
> 
> The password server and libshouldbeinlibc should be changed to use the
> interfaces and usernames instead of uids internally.
> 
> Also the utilities using the password interfaces should be updated so
> they pass the username to the password server instead of the uid.

Note that this is an interface change.  We would like to have versioned
libhurduser and libmachuser before that, a wholly different task ;)
 
> -------------------------------------------------------------------------------
> 
> (ext2fs)
> Maybe file_pager_write_page should be able to accurately reproduce holes
> 
> priority: 3
> difficulty: 5
> 
> When a block that is a part of a file is filled with zeros it doesn't
> have to be stored on disk. This is called a sparse file.
> 
> Just before a block of a file is written to disk file_pager_write_page
> should check if that block is filled with zeros. It should allocate a

should _not_ allocate

> block on disk but just mark it as sparse instead. If a block was
> already allocated on disk it should be freed.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/