* The Linux 2.4 support in scripts/scan.d/33adapter_dt_nosysfs may be
  broken for things like fibre-channel.  It and src/adapter_pci_map.c
  may compare subtypes too strictly.

* Similarly, need to (re-)implement copying of missing device-tree
  segments for hotplug.

* Implement support for getting physical locations for items in a SCSI
  enclosure, probably only on IBM pSeries.

* Locking.  Consider whether /var/lib/lsvpd should be locked when
  update-lsvpd-db is running.  Currently multiple executions of
  update-lsvpd-db can occur concurrently with little risk.

* Implement VPD bus aliases that use a flattened namespace so the
  query commands can find all of the VPD by processing a single
  directory.  This could be done by flattening the directory
  structure, replacing each '/' with '%'.  This may not be faster if
  the directory gets *very* big.  The links would probably point to
  the parent directories, so the sort order would be correct.

  A compromise would be to duplicate the structure and have it contain
  only links to the VPD directories (or their parents).  The advantage
  of this approach is that the directories would be quite sparse and,
  for the device-tree case, wouldn't contain irrelevant
  subdirectories.  Therefore, find should work quicker.

* Move file and directory creation and removal functions like
  lsvpd_mkdir and lsvpd_rm_rf to a file that includes lsvpd.h and make
  them check file or directory arguments against lsvpd_db_dir.

* PN and EC from EEPROM of certain network cards.

  I've now noticed that for 14106902 (although not for the "14108902"
  - also an e1000-based card), the PN and EC appear near the end of
  the EEPROM, which can be got at via the ethtool interface:


  io-bears:~/martins # ethtool -e eth1
  Offset          Values
  ------          ------
  0x0000          00 02 55 d3 5c 56 30 05 ff ff ff ff ff ff ff ff
  0x0010          80 c3 03 64 03 46 69 02 14 10 26 10 86 80 e8 34
  0x0020          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0030          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0040          0c c3 86 72 00 35 02 21 c8 04 ff ff ff ff ff ff
  0x0050          ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06
  0x0060          2c 00 00 40 04 11 00 00 ff ff ff ff ff ff ff ff
  0x0070          ff ff ff ff ff ff ff ff ff ff ff ff ff ff dd 5c
  0x0080          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0090          ...
  0x01f0          30 30 50 36 31 33 30 48 31 32 38 31 38 20 38 55

  In this case we see:

    PN @ 0x01f0 (7 bytes) = 00P6130
    EC @ 0x01f7 (6 bytes) = H12818

  However, there doesn't seem to be anything else.

  Write a templating system (based on
  vendor/device/subvendor/subsystem-id) to parse the contents of the
  EEPROM.

* VPD from EEPROM on Digi 80P4353 serial card.  This is awaiting
  device driver support.

  sa1         U787E.001.AAA0010-P2-C1-T1    2-Port Asynchronous EIA-232
                                            PCI Adapter

        Displayable Message......... 2-Port Asynchronous EIA-232 PCI Adapter
        Part Number................. 80P4353
        FRU Number.................. 80P4353
        Manufacturer................Digi
        EC Level....................H13251
        Serial Number............... 014132959
        Device Specific.(YL)........U787E.001.AAA0010-P2-C1-T1

* Consider whether
  src/device_scsi_sg_map.c::device_scsi_sg_map_setup() should remove
  any device nodes it creates.  Is it possible to use chroot?

* Consider making PCI 2.2 VPD dynamic.  That is, make the query
  commands retrieve it.

* More adapters in lsmcode.

* Physical location aliases?

* Support system-wide N5 and N6 fields on pSeries:

    The next 2 keywords are also system-wide and are present only on
    systems with a Capacity Upgrade on Demand Capacity Card. N5
    represents the licensed entitlement of Capacity Upgrade on Demand
    (CUoD) processors. N6 represents the licensed entitlement of CUoD
    memory. The values for N5 and N6 are generated by making the
    "ibm,get-system-parameter" RTAS call.

  This is pending a stable RTAS interface... and demand.

* Implement hooks for hotplug and look at dynamic /proc/device-tree.

* Implement a regression testing suite.  This would allow testing of
  various components, although wouldn't allow testing of the overall
  system.

* Ethernet & SCSI adapter VPD is currently synthesised in a minimal
  way.  

  In the longer term some sort of real VPD retrieval needs to be
  implemented. I'm going to look at getting binary blobs with the
  contents of PCI expansion ROMs in /sys.  Note: this happened in
  2.6.10, but I had nothing to do with it...  :-)

* ...
