Re: looking for open tasks

hi folks,
thanks for all your input.
We have chosen the partitioning, roughly as described in the mail i'm
replying to. Expect first questions to begin pouring in about two weeks
from now ;)

Ingo, you seem to be The Man for this part of the kernel - if we need
some clarifications, can we contact you directly or should we use the
mailing list?

regards,
jan matejek


Ingo Weinhold napsal(a):
> 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
> _______________________________________________
> Open-beos-kernel-devel mailing list
> Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel
>
>
>   

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