Google Summer of Code 2011 Ideas

From ReactOS Wiki
Revision as of 16:33, 23 February 2011 by Z98 (talk | contribs) (Created page with "== Project Suggestions == === BFS Installable Filesystem Driver for NT === Objective: Create a filesystem driver permitting read and write access for the BFS filesystem. As BFS…")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Project Suggestions

BFS Installable Filesystem Driver for NT

Objective: Create a filesystem driver permitting read and write access for the BFS filesystem. As BFS possesses a rather rich set of metadata functionality, it serves as a workable placeholder for NTFS. A BFS filesystem driver would serve as a testbench against future development of the filesystem runtime library and common cache on ReactOS. In addition, the driver would allow a certain amount of interoperability with the likes of Haiku.

Goals: Working BFS driver that runs in Windows XP or later.

  • Milestone 1: Ability to mount and read BFS partitions.
  • Milestone 2: Ability to write to BFS partitions without extensive metadata attributes.
  • Milestone 3: Ability to write and edit BFS metadata attributes.

Performance Data Registry

Access to performance data on Windows is done primarily through the registry API, accessing something known as the performance data hive. This hive does not exist as a genuine file but is in reality a collection of data exported by various OS components, drivers, services, and even applications. The Windows Task Manager is an example of an application that queries the performance data hive. Condor is another application that uses the performance data hive.

Missing Functionality:

  • Centralized exporting of data (counters) meant for the performance data hive. Currently information from the memory manager, scheduler, and I/O manager are all scattered across multiple data structures or locations. These should be more concentrated so that reading and writing these values do not require jumping around random places in memory. This data is also not shared and will likely require placement in shared, non-paged memory.
  • Tracking system for performance counters. Publishing of performance counters can be done by many different components and applications. A mechanism must be implemented that keeps track of who is publishing this data, where the data is, and what kind of data is being published.
  • The registry functions used to access the performance data hive must be extended to deal with the data structures in the performance data hive. The layout is very different and for all intents and purposes does not match the regular registry's hierarchy at all.
  • A wrapper API was released in Vista that abstracts away the need to use the registry API to access performance counter data.