$Id: TODO,v 1.239 2001/10/01 22:50:59 davej Exp $

This file is a rough roadmap of what to expect in the versions
ahead. Don't be surprised to see things shuffled around periodically.
Things may be put back or brought forward arbitrarily.


0.99.5
~~~~~~
* Reread state (config file|hardware) options for UIs.

* Finish DMI backend.

* devfs will make the cpuid/msr driver explode.
  Print a warning about it. "devfs detected, see FAQ"
  will be sufficient, if it explodes, it explodes. SEP.
  Update : After fixing CPU backend bugs, this works on
  recent Mandrake Linux.

* Info only mode for UIs.
  Powertweak is doing 90% of what hwbrowser and friends are
  already doing. gpowertweak could for eg check argv[0], and
  if its gpowerinfo or whatever, only show info tweaks.
  I've had an 'info only' tool in mind for a long time, and
  thinking about it, it doesn't make sense to duplicate code
  in yet another project.

* 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 be unloaded last,
  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.

  To find out if a core plugin can be unloaded, we may need to implement
  'use' counts, that get incremented when another backend 'registers'
  itself as a user, and decrements when it unloads. If a core plugin
  is at 0 use after we've initialised, it should be safe to unload.

* Integrate Drew Hess' i850 code.
  (Code is there, just needs PCILIB plugin)

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

* Add <STEPPING> tag to PCI backend XML parser.
  Check out http://www.slota.com/reviews/chipsets/superbypass/
  (only for certain revisions of the pciset)
  AMD-751 broken rev C5 (0x25)

* A plugin to support binding network cards to CPUs.
  Much needed for 2.4 network performance.
  Just involves writing CPU # to /proc/irq/affinity iirc.

* PCI backend needs to be taught about radio buttons.
  - VIA 82C691 Memory interleave tristate widgets.
  Mostly done, needs testing.

* daemon/socketlib.c and backends/client/socketlib.c are virtually
  identical. The error checking should be handled in a different
  way before it can be merged into libpowertweak however.

* Logging.
  Make the daemon & UI write to /var/log/powertweak.log
  This should help out a lot debugging strange reports.
  Also make loglevel adjustable.

* Test with efence, memleak & assorted tools.

0.99.6
~~~~~~
* periodic communication from UI to daemon.
  "Send me updates if any tweaks have changed"
  The way usbview does this seems acceptable.
    timer = gtk_timeout_add (2000, on_timer_timeout, 0);
    and a callback to reinit the timer, and do whatever we need.
  (Check for pending msgs, and act accordingly)

* hotplug devices.
  Refresh things like the PCI backends tree every so often.

* Additional backends taking advantage of 'tweak refresh'.
  This feature will be needed for tweaks that constantly change,
  for eg, info tweaks on CPU speed, temperature, load etc.

* CPU clock speed/voltage adjustment.
  - Requires the `periodic update' feature.
  - Kernelside code for this exists in cvs.arm.linux.org.uk
    x86 implementations need finishing.
  - When kernelside finished, rip out the PowerNOW stuff in Powertweak.

* Recognition of when power supply changes from mains to battery
  (and vice versa) by periodically polling apm/acpi, and adjusting
  profile accordingly.

* cpu/x86/mtrr backend.
  - Check for ranges that may be added which the kernel didn't pick up.
  - Possibly rearrange for maximum RAM coverage.
    Recent 2.4 kernels do this (See winchip/CyrixIII patch in setup.c)
  - Check that the BIOS hasn't set MTRRs up in a non-sane manner.
  For example, Intel does not support overlapping of 2 or more MTRRs
  unless 1 of them is of type=uncacheable. If this situation occurs,
  the CPU will default to marking the range uncacheable, and a
  significant performance decrease may occur for those addresses.

* Test with efence, memleak & assorted tools.

0.99.7
~~~~~~
* Cluster support.
  Tweak remote systems.
  - Instead of talking via domain socket, use regular tcp/ip socket.
  - Protocol needs a "What version powertweakd are you" msg
    so that UIs can refuse to speak to newer daemons.
  - Authentication code needs rewrite.
    (ties in with the next feature..?)

* Grant selected non-root users access.
  Worth opening a potential security problem ?
  "sudo" works.
  [AV] If we do anything, I think it should be PAM-related. Even though
       PAM is evil, it is a pretty decent and central permission system.

===================================================================
Other stuff to be added between now and 1.0.0

Scalability issues.
~~~~~~~~~~~~~~~~~~~
* When we have a lot of tweaks in the tree, the UI can take a while
  to start as it needs to pull the whole tweak tree across the socket.
  (This would be even more painful when we adapt to tweak remote
   boxes over IP). We may need to start thinking of ways to minimise
  the amount of data we send.  Initial idea is to request/send subtrees
  only when they get expanded in UIs.
  This also ties in with the "Don't poke things we haven't changed"
  methodology of the planned config parser rewrite.
* We can also save time by not sending info tweaks that can't
  change (device names etc) a second time.
  This requires that register_tweak take an extra argument to store
  flags like "WILLNEVERCHANGE"

Documentation.
~~~~~~~~~~~~~~
* Basic "how to install" stuff... seems ok
* A "users guide".
* How to add a proc/pci tweak to xml 
* Plugin Writers Guide

Indexing for aliases.
~~~~~~~~~~~~~~~~~~~~~
* 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 indexes, and move the checking out of the individual
  XML files into the index.

  The backend loads one xml 'index' file which contains vendor/device
  pairs and a filename to load for that device. This would also speed
  up the current parser, as we wouldn't need to load files that we know
  won't be of any use.

  Example:
	<PCIDEV file="spong.xml">
	  <PCIENTRY vendor="10de" device="0029">
	  <PCIENTRY vendor="10de" device="0030">
	</PCIDEV>

  The CPU backend could also use something very similar...

	<CPU file="PentiumIII.xml">
	  <CPUENTRY vendor="GenuineIntel" family="6" model="7">
	  <CPUENTRY vendor="GenuineIntel" family="6" model="8">
	</CPU>

  This could also clean up all the garbage we currently have in
  the MSRENTRY parser, which can only be a good thing.

CPU backend.
~~~~~~~~~~~~
* Improve the operator support "Model>8" etc.. as well as stepping.
  See aliases/indexes idea above.
* Display x86 cache info.
* Add support for old Cyrix set6x86 style tweaking.
* Add other architectures.
* Write MSR XML for more CPUs.
  - AMD K5
  - Cyrix III
  - IDT Winchip
  - Intel PII
  - Transmeta Crusoe
  I want to wait until we've got something like the indexes idea
  in place before adding all these.

Profiles.
~~~~~~~~~
* Translate existing profiles to new PROC config names
  Done, except for wildcarded entries.
  (Do this after the CONFIGNAME renaming mentioned above).
* UIs need to give users the ability to decide when certain
  profiles get loaded under which event. 
* A better profile creator than $EDITOR
* Handle clashes between multiple profiles better
  (Ie, inform the user, and ask what to do).
* Wildcards in profiles.
  Things like the disk elevator are per device, and some of
  the networking items need wildcard support too.
* Advise on usage of a profile if criteria is met.
  For eg, if a gigE card is found, advise loading the
  gigabit profile.

Other..
~~~~~~~
* Config Parser needs rewriting.
  - Save only values that are changed to the config file
  - Allow backends to use alternate save mechanism
  - Get confignames standardised.
  	Planned changes:
  	- PIV_LOW_POWER_MODE  -> P6_LOW_POWER_MODE
  	- SMART_ENABLE_/dev/hda -> SMART_ENABLE_hda
  	- hda_ELEVATOR_READ_LATENCY -> ELEVATOR_READ_LATENCY_hda
  	- KERNEL-SHMALL -> kernel/shmall
  	- NET_TCPIP_DEV_* -> net/tcpip/dev/*
  - Autoconf needed for specifying where config file loads from
  - Don't save tweaks from info backends at all
    (see what we do with DMI right now).

* Is it worth playing with breada_readahead & file_readahead
  in /proc/ide/??/settings
  Check with Jens.

* Shutdown code is duplicated in UIs.

* Improve TUX sysctls. Needs multiple choice settings.

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

* Addition of extra tweaks to the proc-misc backend. 
  - In ipv4/ip_local_port_range, we have a 2 value field & we need to
    validate that value1 is < value2
  - the vm/bdflush sysctl has changed meanings in 2.4
    (some fields don't do anything any more)

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

* Prettying of the GTK GUI. (Uberlow priority).
  - PNG for a Splash screen / about screen.
  - Icons in ctree?
    Doing something similar to the 'settings' dialog in Galeon shouldn't be
	too hard, and would look really good in the GTK GUI. The YaST2 frontend
	can also use these.
	Each backend registers a path to the icon to be used in the tree.

* 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. Also
  an "enable ext3" button, and assign labels. 

* Extra hdparm backend functionality.
  - Basic support for common hdparm switches.
  - We can also 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).
  - Note, Andre wants hdparm to go away in 2.5.x kernel.

* BIOS backend.
  Primarily informational, to discover if BIOS options have been
  enabled without needing to reboot.
  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).

* Motherboard specific backends
  - BP6 FSB frequency tuning.
    (Possible on a few ASUS boards too, and maybe others)
  [AV] SoftFSB -> http://hp.vector.co.jp/authors/VA002374/src/download.html
 
  - 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.

* 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 ;-)

* More laptop futzing.
  Toshiba:
   http://schwieters.org/toshset.html
   http://www.buzzard.org.uk/toshiba
  IBM Thinkpad:
   (tpctl)

