$Id: TODO,v 1.146 2000/12/18 18:49:10 davej Exp $

Between this release and 1.0.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Textmode UI.
~~~~~~~~~~~~
Fix strange interaction between some terms & ssh losing ALT keys.

Profiles & /proc XML
~~~~~~~~~~~~~~~~~~~~
Translate existing profiles to new PROC config names
Done, except for wildcarded entries. (For 0.99.1)

Build process:
~~~~~~~~~~~~~~
* Autoconf needed for..
  : Specify where config file loads from

Documentation.
~~~~~~~~~~~~~~
* Basic "how to install" stuff... seems ok
* A "users guide".

PCI backend:
~~~~~~~~~~~~
* http://www.overclockers.com/tips105/index03.asp

* Allow an XML file to be used for multiple devices.
  A few chipsets/devices have different IDs, but are register
  compatible. Rather than duplicate the xml file, we need to implement
  alias lists.
    <ALIASES vendor="10de" device="0028">
      <ALIAS vendor="DEAD" device="BEEF"/>
      <ALIAS vendor="8086" device="0000"/>
    </ALIASES>
  and make sure somehow that if the current device is listed as an
  alias, the tweak is accepted anyway.

* Merge in missing tweaks.
  - I've been sent a few config files from various Windows programs that
    do Powertweak type PCI tuning. Need to double check them before I
	add them, but most look quite sane. (Things like Intel i810, i820,
	i840, and some of the newer VIA chips + 1-2 rare things)
  - Port & Check the PCI tweaks from 0.1.x
    AMD 751 needs going over carefully, theres a problem somewhere
  - I've a few things that I've been playing with for cards like 3dfx.
    These should be complete enough to add to 1.0.0, but requires some
	of the other features to be added first (Like core plugins, namely
	PCILIB)

* <STEPPING> tag.
  Check out http://www.slota.com/reviews/chipsets/superbypass/
  (only for certain revisions of the pciset)

CPU backend.
~~~~~~~~~~~~
* Improve the operator support "Model>8" etc.. as well as stepping.
* Write MSR XML for more CPUs.
* Display x86 cache info.
* Add support for old Cyrix set6x86 style tweaking.
* Add other architectures.

Other..
~~~~~~~
* Move more duplicated routines out of the GUIs/backends into
  libpowertweak. The socket stuff contains quite a lot of duped code.

* GTK GUI's show_error() function should work like printf().

* Not all backends know about all the widget types.
  This is ok for now, as our XML's aren't using them.

* Wildcards in profiles.
  Things like the disk elevator are per device, and some of
  the networking items need wildcard support too.

* Core plugins.
  These will be loaded before all the other plugins
  from plugins/core/* the reasoning behind them is best explained
  if you think of a backend such as 'graphic card clock adjuster'.
  It will need access to PCILIB routines. Rather than duplicate
  PCILIB in >1 backend, making PCILIB its own backend is better.
  If a core plugin fails for whatever reason, it must not be unloaded,
  or reliant backends will die with unresolved symbol errors.
  The backends should call a function in the core plugin to find
  out if all is ok before using its functions.

* Documentation.
  - How to add a proc/pci tweak to xml 
  - Plugin Writers Guide

* Backend for special case /proc/sys stuff.
  For things like ipv4/ip_local_port_range, where we have a 2 value
  field & we need to validate that value1 is < value2
  The various things shm, local_port_range etc will still be kept in
  separate source files, but compile into one plugin.

* Add the new 2.4.x /proc tweaks.
  [AV] Better wait a bit, they might change
  [DJ] Agreed, should be ok by the time we're ready for v1.0.0

* The tooltips can be annoying.
  Some kind of "I haven't moved the mouse for a second" delay
  is needed. This may be quite hairy, haven't investigated at
  all yet.. Gnumeric does this fine, so it may just be a case
  of stealing^Wborrowing some more code.
  [AV] Gnome sucks!

* Tweaktree updating in daemon mode.
  The daemon should refresh its tweaktree whenever a connection
  is made by a UI.

* In daemon mode, unload plugins after startup, reload on
  connection by a UI. Has implications for plugins that
  want to stay around monitoring state. Can be fixed if plugins
  return something back to the daemon saying "Don't unload me".

* Backend processes.
  This kind of thing will be needed for the power management
  stuff & load monitoring that's planned.

* Prettying of the GTK GUI. (Uberlow priority).
  - PNG for a Splash screen / about screen.
  - Icons in ctree? (Involves parsing nodes and knowing about
    strings that backends may use -- may get ugly.)
	Mandrake's harddrake tool has some nice icons to borrow.

* VPD (See PCI spec) looks to be something interesting that could extend
  the PCI info pages.
  Depends how many devices actually support this feature.

* tune2fs backend.
  Setting of some features can increase available diskspace (-m), reduce
  fsck frequency (-c). Scan hard disks on startup looking for ext2
  partitions, and add them to the appropriate Disk/hdX menu.

* hdparm backend.
  As well as the obvious 'dma on' type switches, we can do tests
  to ensure that the combination of drive + chipset/controller BIOS is
  good.   Also blacklist drives known to have problems (certain WDC's
  for eg).
  There's a progam 'IDETool' written by Alan Cox in gnome-utils which
  may have some code worth using for an `info' page.
  This will live under the 'Disk' tree item along with elevator
  tuning etc..   Things like the SMART tools would also fit well here.

* BIOS backend.
  Primarily informational, to discover if BIOS options have been
  enabled without needing to reboot. Also libdmi will be a good
  thing to add to this.
  I have code to query expansion ROMs of various cards too.
  Things like the extended Matrox info in 0.1.x
  Reliant upon core-plugin (PCI).

* Grant selected non-root users access.
  Worth opening a potential security problem ?
  "sudo" works.

* Motherboard specific backends
  - BP6 FSB frequency tuning.
    (Possible on a few ASUS boards too, and maybe others)
  - ARM may also benefit from this.
  - Maybe info pages interfacing with the lm_sensors /proc stuff?

* hardware clock adjustment.
  Various graphic cards allow adjustment of the various onboard
  clocks. If possible try to make this generic so all the different
  gfx cards can share at least _some_ common code.

* duty cycle adjustment.

* AMD PowerNow! / Intel SpeedStep support.
  Being researched. Will require the `periodic update' feature.

* Support for lm_sensors.
  Should be simple enough, we have the relevant /proc/sys stuff
  already, just requires the backend processes feature, and a
  method of the backend/daemon telling the GUI every so often
  that "X has changed".

* ipchains / iptables / whatever-its-called-this-week plugin
  - TOS bit manipulation.
    http://www.linuxdoc.org/LDP/nag2/x-087-2-firewall.tos.manipulation.html
  Doesn't seem to be a measurable win (At least not on a 56k modem),
  may not be worth the effort involved.

* Config file tuning backend.
  - Will need procedures for things like getting/setting the value of
    config items. Tricky to write generically due to the different
    types of config file.
  - Adjusting various config files (NFS, Samba, Apache) to turn on
    switches which boost performance.
  - fstab tuning
    - setting of noatime on /var and other mounts
    - fs specific features (tailpacking on reiserfs etc..)

* SuperIO tuning.
  Some chips allow higher transfer rates to be set.
  http://hp.vector.co.jp/authors/VA004958/over115K/index_e_old.html
  Some chips require kernel changes though.
  This code is available, but has no license associated with it.
  Warning #2: If you decide to play with the .c file in the archive
  on this site, be warned it seems to have a bug (at least on SMC
  controllers) where the clock jumps forwards/backwards 2hrs every
  30 seconds or so. Amusing, but worrying ;-)

* Clustering support.
  Tweak remote systems.

