1. 09 Jun, 2004 1 commit
    • Leigh B. Stoller's avatar
      Add floorimages and buildings tables for wireless floormap support. · 632ef32b
      Leigh B. Stoller authored
      This is rather primitive still; We just need a place to define
      buildings and floors in buildings, so that we do not hardwire them
      into the code. This can get arbitrarily complicated, but not until we
      need it.
      	CREATE TABLE buildings (
      	  building varchar(32) NOT NULL default '',
      	  image_path tinytext,
      	  title tinytext NOT NULL,
      	  PRIMARY KEY  (building)
      	) TYPE=MyISAM;
      The image_path is optional for buildings. The title is a string to
      print along with the images (Merril Engineering Building).
      	CREATE TABLE floorimages (
      	  building varchar(32) NOT NULL default '',
      	  floor varchar(32) NOT NULL default '',
      	  image_path tinytext,
      	  thumb_path tinytext,
      	  x1 int(6) NOT NULL default '0',
      	  y1 int(6) NOT NULL default '0',
      	  x2 int(6) NOT NULL default '0',
      	  y2 int(6) NOT NULL default '0',
      	  PRIMARY KEY  (building, floor)
      	) TYPE=MyISAM;
      The image_path is not optional; it is either an absolute path or a
      filename in $TB/www. The thumb_path is for a tiny view of it. Floor is
      something like 1, 2, 3 but could also be basement, lobby, penthouse,
      etc. The x,y coordinates are intended to be bounding box coords of the
      "interesting" part of the image so that it is easier to scale specific
      entries from the location_info table. But, not really sure about this
      yet; needs more thought and some investigation about appropriate ways
      to store coordinate values like this.
  2. 08 Jun, 2004 2 commits
    • Leigh B. Stoller's avatar
      Add another index to virt_lans. · d1998932
      Leigh B. Stoller authored
    • Leigh B. Stoller's avatar
      Add slots to virt_lans to rationalize the relationship between · 43a804e9
      Leigh B. Stoller authored
      virt_lans and virt_nodes. The intent is to migrate away from
      the convention we use in virt_nodes:ips and virt_lans:member
      to a more acceptable representation (one that does not rely
      on textual conventions like space separated lists of colon
      seperated entities. Instead:
      		vname:	nodeA
      		vname:  link0
      		vport:  0
      		vname:  link1
      		vport:  1
      	alter table virt_lans add vnode varchar(32) NOT NULL default '' \
      		after vname;
      	alter table virt_lans add vport tinyint(3) NOT NULL default '0' \
      		after vnode;
              alter table virt_lans add ip varchar(15) NOT NULL default '' \
      		after vport;
      Then run this script to update these new fields from the
      existing ips,member slots. This must be run after installing
      the parser changes, or you can just run it again.
      This is a transitional phase; the old slots will be left in place
      until they are no longer used, at which time we will also add a
      unique key to the table (pid,eid,vname,vnode,vport). assign_wrapper
      will be the hardest to change, but other scripts should be easy.
      Whats vport about? Rather then rely on IP addresses to form a
      unique key, we use vport (a small integer) so that we can delay the
      IP assignment until later (after initial DB insertion).
  3. 04 Jun, 2004 1 commit
  4. 01 Jun, 2004 1 commit
  5. 25 May, 2004 2 commits
  6. 21 May, 2004 1 commit
  7. 18 May, 2004 1 commit
  8. 07 May, 2004 1 commit
  9. 03 May, 2004 1 commit
    • Leigh B. Stoller's avatar
      Change to eventlist table; bump size of vname from 20 to 64. I do not · d5c51dd2
      Leigh B. Stoller authored
      see (or remember) any reason for this slot to be 20 chars, when the
      name of every other vname slot is 32. I looked in the event scheduler
      and there do not appear to be any problems there with bumping it. Note
      that I choose 64 cause we tend to construct agent names that might be
      longer then 32 since they are based on real vnames (lan0, node0, etc).
  10. 19 Apr, 2004 1 commit
  11. 15 Apr, 2004 1 commit
  12. 09 Apr, 2004 1 commit
  13. 08 Apr, 2004 1 commit
  14. 07 Apr, 2004 2 commits
    • Leigh B. Stoller's avatar
      Add linktest_level to experiments table. Value is 0-4, where 0 means · 10cef776
      Leigh B. Stoller authored
      not to run linktest.
    • Leigh B. Stoller's avatar
      Initial DB support for wireless nodes. Added a "protocol" text field and · 90a6e82b
      Leigh B. Stoller authored
      an "is_accesspoint" boolean to virt_lans. The former defaults to
      "ethernet" but can be set to anything (80211a, 80211b, etc) in the NS
      file. The is_accesspoint is temporary, and simply allows you to set
      which node is the accesspoint in the NS file. This slot will probably
      move to another table at some point.
      Added interface_capabilities table, which is intended to list the
      capabilities and the default values, for interfaces listed in the
      interface_types table. This allows a more flexible description of
      interfaces, expecially wireless devices. Initially, I have seeded the
      table with just the default protocol (ethernet) and the speed. For
      example, the fxp:
      	fxp              | protocols         | ethernet |
      	fxp              | ethernet_defspeed | 100000   |
      As you can see, protocols is plural, and is intended to be a comma
      separated list. So, for the atheros wireless card:
      	ath              | protocols         | 80211a,80211b,80211g |
      	ath              | 80211a_defspeed   | 54000                |
      	ath              | 80211b_defspeed   | 11000                |
      	ath              | 80211g_defspeed   | 54000                |
      I gave up on using the entire row as a primary key; this is just too
      painful from perl/php/python where hashes are the most popular data
      structure, and duplicate columns get overwritten.
  15. 25 Mar, 2004 2 commits
  16. 23 Mar, 2004 1 commit
  17. 04 Mar, 2004 1 commit
  18. 02 Mar, 2004 1 commit
  19. 25 Feb, 2004 1 commit
  20. 17 Feb, 2004 1 commit
  21. 12 Feb, 2004 1 commit
  22. 05 Feb, 2004 2 commits
  23. 04 Feb, 2004 1 commit
  24. 02 Feb, 2004 1 commit
  25. 31 Jan, 2004 1 commit
  26. 28 Jan, 2004 2 commits
  27. 14 Jan, 2004 1 commit
  28. 06 Jan, 2004 2 commits
  29. 05 Jan, 2004 1 commit
  30. 31 Dec, 2003 1 commit
  31. 28 Dec, 2003 1 commit
  32. 27 Dec, 2003 1 commit
  33. 25 Dec, 2003 1 commit