Re: [Linux-NTFS-Dev] Joining Linux NTFS Development

[Yuval <yu...@gm...>]

Hi,

Here is the first few proposed A's of the "FAQ for Beginning
linux-ntfs Developers"
>  1.  What is the best testbed for ntfs development work?  (i.e. do people
> test their possible buggy/corrupting code within vmware or do they use a
> physical disk within their own system?)

It is really a matter of personal preference:
- If you don't care about the data in your NTFS partition, you may use
a physical volume. It will be faster. bare in mind that using a
physical partition means dual booting with windows to check for
consistency.
- VMWare & co. have the pro of allowing you to run both windows and
linux on the same time. As such, it allows shorter turn around
between.
- Linux allows mounting a file instead of a partition. if you like to
do testing on a particular case. you may backup the file and restore
it every time until you don't crash.
Related yet off topic answer:
- You can write buggy/corrupting code on the user space
(libntfs/ntfsprogs or UML).

>  2.  Is the NTFS spec available or does reverse-engineering work need to =
be
> done for the driver?

Most of it is available.
The problem here is not the spec, but that we need to make sure not to
fall on corner cases that the Windows driver does not handle. Examples
are certain attributes that must be resident, attribute sizes, etc.
Such cases are usually documented in the code (so you can consider it
as non documented).

>  3.  How do I submit code for inclusion in the driver?  Is a simple patch=
 to
> the mailing list sufficient?

Send the first few patches to the list for review.
Later you'll gain trust and know how to bypass the list.
If you send kernel patches, don't forget the Signed-off-by line and
make sure you know what that means.

>  4.  Is there a master 'todo' list for the project and if so, how do I
> ensure that I do not work on something that somebody else is already work=
ing
> on? =20

There are a few.
I wanted to consolidate those, but that didn't worked out.
There is also the driver roadmap on some (remote) email.

And some more Q's with A's:
- where is the most recent code?
The kernel's driver code is on the following GIT repository:
{rsync,ftp,http}.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs-2.6-devel.g=
it
The user space tools/library and the website are on sourceforge's cvs.

- What can I do to help:
Whatever you like. you can code, document, advocate, helping users or
maintain the website. (not necessarily on that order)

- How do I start:
1) Join the dev mailing list.
* If you choose coding:
2) do something
3) send the patch for review
4) fix it according to the comments you got, and go back to 3.
5) enjoy watching it being merged. and go back to 2.
* If you choose documenting.
2) Read the documentation.
3) Search the code for undocumented stuff.
4) Update the documentation.
5) Send the patch against the documentation CVS to someone (preferably
to FlatCap/Yuval)
6) Find missing peices.
7) ask about them on the mailing list.
8) If no one knows, reverse engineer to find out.
9) go back to 4.
*If you choose advocating.
1) Use your personal carisma.
*If you choose helping users:
1) Track the user's mailing list and various fourms on the web.
2) Use google to find similar cases on the web. It is usually
disribution dependant.
3) Ask questions on the dev mailing list if you are lost.
*If you choose updating the website.
1) Checkout the website CVS from sourceforge.
2) Do whatever you like
3) Send patches to the mailing list and wait.
4) You'll find out about 4 when you get to it.

[That was longer than I thought.]

Sincerely
-- Yuval