|
From: Anton A. <ai...@ca...> - 2004-05-12 22:39:11
|
Hi, On Tue, 11 May 2004, Will Glynn wrote: > FYI, I've been lurking the lists for many months. Nice to see you surfacing. (-: > > > Something about what, and how, people could help. > > > > We keep scaring people off. Beginners don't want to do the boring tasks > > and they can't manage the sexy stuff. > > True. I, for one, have a fairly good grasp of how NTFS works, in no small part > due to the information published on the Linux-NTFS website. (I ended up > writing an NTFS recovery toolset from scratch some time ago, which is how I > ended up knowing what I do.) I have some amount of free time, and I'd like to > see a write-capable NTFS driver, but I don't have any idea of where to start. > The driver mystifies me, and there don't seem to be any resources describing > its structure or status. > > From my perspective, the driver is a big fog. Knowing more about the kernel > would probably help (doesn't it always), but even so. I think the lack of > information -- or the low visibility of whatever exists -- is a serious > problem, and major factor in "scaring away" prospective developers. When I started writing the new driver there were a few good books on the kernel available online. I will see if I can find the URLs for them and see if they still exist / make sense with 2.6 kernels and email them to the list. They would definitely be required reading material to even stand the slightest chance of understanding the driver. Considering you have written tools I imagine you know C pretty well. That would be another prerequisite to doing kernel development. (C++ not allowed.) You also need to have understood and agreed with the kernel coding standards. Once one digests those one quickly gets used to them and then reading code (that adheres to them) is a LOT easier to do and to understand. I am now so familiar with it that I can just read some kernel code I have never seen before and immediately focus on what it is doing and understand it rather than having to stare at the looks and take a lot of time to extact the "what it actually does" from the "looks". A few years ago Rich and I spent about a week where I explained how the driver worked/was built up to him using IRC to talk to each other and a shared terminal windows (using the screen window manager) to show the code we were talking about. This was very successful but unfortunately we were not able to record it as the IRC log would not be too useful without the accompanying code display and highlighting at the same time... So I would need to find a lot of spare time to start writing up how the driver works... Maybe one day... For now I suggest anyone wanting to understand the driver to learn the kernel VFS layer first. The way to understand how a kernel FS works is to walk through exececuted code e.g.: system call open() -> sys_open() (in kernel) -> ... follow it through till you end up in ntfs code and follow that through, too. system call read() -> sys_read() (in kernel) -> ... as above. That way you can see how doing something from the user point of view gets into the NTFS code and what the NTFS code is expected to do by the VFS layer. The VFS layer does a LOT of the work for us so understanding it is really important to understand how the driver works... I will try and get those URLs in the next week or two. I am really busy at the moment and this weekend is my wife's birthday and I promised to make her a birthday cake so that will probably wipe out my weekend... (-; Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
