Re: looking for open tasks

On 2007-02-28 at 11:16:36 [+0100], Waldemar Kornewald 
<[email protected]> wrote:
> On 2/28/07, jan matejek <matejcik-IaeKGDb/[email protected]> wrote:
[...]
> > > * implement write support of the disk device manager, and write a
> > > partitioning software using it.
> > These two look promising. Can you provide more details?
> > (what exactly is needed and where in the sources are starting points)
> 
> I think this task could be pretty interesting and you can actually get
> it finished (which is a lot more motivating than a half-broken app).
> The only problem I see is that you might waste time with learning our
> GUI API. Eight weeks are not *that* much and unless you get another
> eight weeks to prepare I think you should leave out userland GUI apps.
> 
> I'd suggest keeping it at the command line:
> * add write support to DiskDeviceManager
> * implement a simple command-line partition manager
> * add support for FS initialization to some of our file systems (if
> that's missing)

The implementation of the required interface is missing for BFS (which would 
be the FS in question), but the code to initialize a partition is already all 
there. So that's a minor task. Interesting would be resizing, though, at 
least increasing the size while not mounted. Don't know how much work that 
would be; Axel can tell, I suppose.

Another requirement is the addition of most write features for at least one 
partitioning system (ideally the one we named "intel" partitioning system, 
i.e. what is used in today's BIOS-based intel-compatible PCs). This includes 
initializing a disk, creating/deleting partitions, resizing and moving 
partitions.

> * implement a command-line file system initialization tool (or extend
> partition manager)

It makes sense to include FS initialization in the partition manager, I 
think. What I have in mind is a simple Linux fdisk like tool that can also 
explicitely move/resize partitions and initialize FSs. It would nevertheless 
be nice to have a non-interactive mkfs command, too.

> In case you get finished earlier than expected we still have other
> nice tasks, so don't worry. ;)
> If the work can't be split among three developers we could add an
> unrelated task like "USB OHCI" or "USB Isochronous Streams" (Niels, is
> the latter small enough?).
> 
> Later, the command-line tools can still be adapted to become a GUI
> application (either by you or us), so please design the command-line
> tools such that it will be easy to adapt the functionality to a GUI
> (separate CLI interface/interaction from partition management code
> where possible).

If the tasks fit what you're allowed to do, the work can be three-way split 
quite naturally: One would do the userland tools, one would extend the file 
and partitioning system kernel modules (BFS, intel), and one would implement 
the support needed in the DDM.

The userland tools are probably the least of the work, but you can change 
that by making them GUI. There's also a userland add-on (GUI) interface still 
to be defined for editing the parameters a file or partitioning system 
supports.

The kernel modules shouldn't be too much work either. If needed you can add 
more features (defragmenting and shrinking BFS, doing all that live, i.e. 
while mounted; we also have other FSs that could be extended).

The part I'm least sure about is the DDM itself. It actually shouldn't be 
that much work, but the whole beast, including the userland API, and the 
file/partitioning system interfaces were designed from the scratch. So I 
wouldn't rule out that you could hit a design flaw that would require major 
changes.

CU, Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV