5"8 2"4/spa4.4 2"4/form.4 2"4a 5"8 2" href="../linux+v3.9.1/Documenta v4/usb/WUSB-Design-overview.txt">5"8 2"4img src="../.sta c/gfx/right.png" alt=">>">5"4/spa4.45"4spa4 class="lxr_search">5"8 5"8 2"4input typ'0 hidden" nam'0 navtarget" 5322'0 ">5"8 2"4input typ'0 text" nam'0 search" id0 search">5"8 2"4buttv4.typ'0 submit">Search5"8 2"Prefs4 2"4/a>5"4/spa4.48 2" "4/div.48 2" "4form ac v4="ajax+*" method="post" onsubmit="return false;">5"4input typ'0 hidden" nam'0 ajax_lookup" id0 ajax_lookup" 5322'0 ">58 2" "4/form.458 2" "4div class="headingbottvm">" "14/a>5" "24/a>Linux UWB + Wireless USB + WiNET5" "34/a>5" "44/a>" "(C) 2005-2006 Intel Corpora v45" "54/a>" "Inaky Perez-Gonzalez <>5" "64/a>5" "74/a>" "This program is free software; you ca4 redistribute it and/or5" "84/a>" "modify it under the terms of the GNU General Public License vers v45" "94/a>" "2 as published by the Free Software Founda v4.5" 270na>5" 114/a>" "This program is distributed in the hope that it will be useful,5" 124/a>" "but WITHOUT ANY WARRANTY; without even the implied warranty of5" 134/a>" "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the5" 144/a>" "GNU General Public License for"more details.5" 150na>5" 164/a>" "You should have received a copy of the GNU General Public License5" 174/a>" "along with this program; if not, write to the Free Software5" 184/a>" "Founda v4,"Inc., 51 Franklin Street, Fifth Floor, Bostv4,"MA5" 194/a>" "02110-1301, USA.5" 270na>5" 214/a>5" 224/a>Please visit 4/a>for5" 234/a>upda ed content.5" 244/a>5" 254/a>" " * Design-overview.txt-1.85" 264/a>5" 274/a>This code implements a Ultra Wide Band stack for"Linux, as well as5" 284/a>drivers for"the the USB based UWB radio controllers defined in the5" 294/a>Wireless USB 1.0 specifica v4 (including Wireless USB host controller5" 370na>and a4 Intel WiNET controller).5" 314/a>5" 324/a>" "1. Introduc v45" 334/a>" """""""1. HWA: Host Wire adapters, your Wireless USB dongle5" 344/a>5" 354/a>" """""""2. DWA: Device Wired Adaptor, a Wireless USB hub for"wired5" 364/a>" """"""""""devices5" 374/a>" """""""3. WHCI: Wireless Host Controller Interface, the PCI WUSB host5" 384/a>" """"""""""adapter5" 394/a>" "2."The UWB stack5" 404/a>" """""""1. Devices and hosts: the basic struc ure5" 414/a>5" 424/a>" """""""2. Host Controller life cycle5" 434/a>5" 444/a>" """""""3. On the air: beacons and enumera ng the radio neighborhood5" 450na>5" 464/a>" """""""4. Device lists5" 474/a>" """""""5. Bandwidth alloca v45" 480na>5" 494/a>" "3. Wireless USB Host Controller drivers5" 570na>5" 514/a>" "4. Glossary5" 520na>5" 534/a>5" 544/a>" ""Introduc v45" 550na>5" 564/a>UWB is a wide-band communica v4 protocol that is to serve also as the5" 574/a>low-level protocol for"others (much like TCP sits v4 IP). Currently5" 580na>these"others are Wireless USB and TCP/IP,"but seems Bluetooth and5" 594/a>Firewire/1394 are com ng along.5" 670na>5" 614/a>UWB uses a band from roughly 3 to 10 GHz, transmit ng at a max of5" 620na>~-41dB (or"0.074 uW/MHz--geography specific data is still be ng5" 634/a>negotia ed w/ regulators, so watch for"changes)."That band is divided in5" 644/a>a bunch of ~1.5 GHz wide"channels (or"band groups) composed of three5" 650na>subbands/subchannels (528 MHz each)."Each"channel is independent of each5" 664/a>other, so you could consider them different "busses". Initially this5" 674/a>driver considers them all a single v4e.5" 680na>5" 694/a>Radio time is divided in 65536 us long /superfram's/, each v4e divided5" 770na>in 256 256us long /MASs/ (Media Alloca v4 Slots), which are the basic5" 714/a>time/media alloca v4 units for"transferr ng data. At the beginn ng of5" 720na>each superfram' there is a Beacon Period (BP), where every"device5" 734/a>transmit its beacon v4 a single MAS."The length of the BP depends v4 how5" 744/a>many"devices are present and the length of their beacons.5" 750na>5" 764/a>Devices have a MAC (fixed, 48 bit address) and a"device (changeable, 165" 774/a>bit address) and send periodic beacons to advertis' themselves and pass5" 780na>info v4 what they are and do."They advertis' their capabilities and a5" 794/a>bunch of other stuff.5" 870na>5" 814/a>The different logical parts of this driver are:5" 820na>5" 834/a>" ""*5" 844/a>5" 854/a>" """"*UWB*: the Ultra-Wide-Band stack -- manages the radio and5" 864/a>" """"associa ed spectrum to allow for"devices shar ng it. Allows to5" 874/a>" """"control"bandwidth assignment, beacon ng, scann ng, etc5" 880na>5" 894/a>" ""*5" 970na>5" 914/a>" """"*WUSB*: the layer that sits v4 top of UWB to provide Wireless USB.5" 924/a>" """"The Wireless USB spec defines means to control"a UWB radio and to5" 934/a>" """"do the actual WUSB.5" 944/a>5" 950na>5" 964/a>" """"HWA: Host Wire adapters, your Wireless USB dongle5" 970na>5" 980na>WUSB also defines a"device called a Host Wire Adaptor (HWA), which in5" 994/a>mere terms is a USB dongle that enables your PC to have UWB and Wireless5"1004/a>USB."The Wireless USB Host Controller i4 a HWA looks to the host like a5"1014/a>[Wireless] USB controller connected via USB (!)5"1020na>5"1034/a>The HWA itself is broken in two or"three main interfaces:5"1044/a>5"1054/a>" ""*5"1064/a>5"1074/a>" """"*RC*: Radio control -- this implements an interface to the5"1084/a>" """"Ultra-Wide-Band radio controller."The driver for"this implements a5"1094/a>" """"USB-based UWB Radio Controller to the UWB stack.5"1270na>5"1114/a>" ""*5"1120na>5"1134/a>" """"*HC*: the wireless USB host controller. It looks like a USB host5"1144/a>" """"whose root port is the radio and the WUSB devices connect to it.5"1154/a>" """"To the system it looks like a separa e USB host."The driver (will)5"1164/a>" """"implement a USB host controller (similar to UHCI, OHCI or"EHCI)5"1174/a>" """"for"which the root hub is the radio...To reitera e: it is a USB5"1184/a>" """"controller that is connected via USB instead of PCI.5"1194/a>5"1204/a>" ""*5"1214/a>5"1224/a>" """"*WINET*: some HW provide a WiNET interface (IP over UWB)."This5"1234/a>" """"package provides a"driver for"it (it looks like a network5"1244/a>" """"interface, winetX)."The driver detects when there is a link up for5"1254/a>" """"their typ' and kick"into gear.5"1264/a>5"1270na>5"1284/a>" """"DWA: Device Wired Adaptor, a Wireless USB hub for"wired"devices5"1294/a>5"1370na>These"are the complement to HWAs."They are a USB host for"connect ng5"1314/a>wired"devices,"but it is connected to your PC connected via Wireless5"1324/a>USB."To the system it looks like yet another USB host."To the untrained5"1334/a>eye, it looks like a hub that connects upstream wirelessly.5"1344/a>5"1354/a>We still offer no support for"this; however, it should share a lot of5"1364/a>code with the HWA-RC driver; there is a bunch of factoriza v4 work that5"1374/a>has been done to support that in upcom ng releases.5"1380na>5"1394/a>5"1404/a>" """"WHCI: Wireless Host Controller Interface, the PCI WUSB host"adapter5"1414/a>5"1424/a>This is your usual PCI device that implements WHCI. Similar in concept5"1434/a>to EHCI, it allows your wireless USB devices (including DWAs) to connect5"1444/a>to your host"via a PCI interface. As in the case of the HWA, it has a5"1450na>Radio Control interface and the WUSB Host Controller i4terface per se.5"1464/a>5"1474/a>There is still no driver support for"this,"but will be in upcom ng5"1480na>releases.5"1494/a>5"1570na>5"1514/a>" ""The UWB stack5"1520na>5"1534/a>The main miss v4 of the UWB stack is to keep a tally of which devices5"1544/a>are in radio proximity to allow drivers to connect to them. As well, it5"1550na>provides an API for"controll ng the local radio controllers (RCs from5"1564/a>now on), such as to start/stop beacon ng, scan, alloca e"bandwidth, etc.5"1570na>5"1580na>5"1594/a>" """"Devices and hosts: the basic struc ure5"1670na>5"1614/a>The main building block here is the UWB device (struc uwb_dev). For5"1620na>each device that pops up in radio presence (ie: the UWB host"receives a5"1634/a>beacon from it) you get a struc uwb_dev that will show up in5"1644/a>/sys/class/uwb and in /sys/bus/uwb/devices.5"1650na>5"1664/a>For each RC that is detected, a new struc uwb_rc is crea ed. In turn, a5"1674/a>RC is also a device, so they also show in /sys/class/uwb and5"1680na>/sys/bus/uwb/devices,"but at the sam' time, only radio controllers show5"1694/a>up in /sys/class/uwb_rc.5"1770na>5"1714/a>" ""*5"1720na>5"1734/a>" """"[*]"The reason for RCs be ng also devices is that not only we can5"1744/a>" """"see them while enumera ng the system device tree,"but also on the5"1754/a>" """"radio (their beacons and stuff), so the handl ng has to be5"1764/a>" """"likewis' to that of a device.5"1770na>5"1780na>Each RC driver is implemented by a separa e driver that plugs"into the5"1794/a>interface that the UWB stack provides through a struc uwb_rc_ops."The5"1870na>spec crea ors have been nice enough to make the message format the sam'5"1814/a>for HWA and WHCI RCs, so the driver is really a very"thin transport that5"1820na>moves the requests from the UWB API to the device [/uwb_rc_ops->cmd()/]5"1834/a>and sends the replies and notifica v4s back to the API5"1844/a>[/uwb_rc_neh_grok()/]. Notifica v4s are handled to the UWB daemv4,"that5"1854/a>is chartered, among other things, to keep the tab of how the UWB radio5"1864/a>neighborhood looks, crea ng and destroy ng devices as they show up or5"1874/a>disappear.5"1880na>5"1894/a>Command execu v4 is very"simple: a command block is sent and a event5"1970na>block or reply is expected back. For send ng/receiv ng command/events, a5"1914/a>handle called /neh/ (Notifica v4/Event Handle) is opened with5"1924/a>/uwb_rc_neh_open()/.5"1934/a>5"1944/a>The HWA-RC (USB dongle) driver (drivers/uwb/hwa-rc.c) does this job for5"1950na>the USB connected HWA. Eventually, drivers/whci-rc.c will do the sam'5"1964/a>for"the PCI connected WHCI controller.5"1970na>5"1980na>5"1994/a>" """"Host Controller life cycle5"2070na>5"2014/a>So let's say we connect a dongle to the system: it is detected and5"2020na>firmware uploaded if needed [for"Intel's i14805"2034/a>/drivers/uwb/ptc/usb.c:ptc_usb_probe()/] and then it is reenumera ed.5"2044/a>Now we have a real HWA device connected and5"2054/a>/drivers/uwb/hwa-rc.c:hwarc_probe()/ picks it up, that will set up the5"2064/a>Wire-Adaptor environment and then suck it into the UWB stack's visiv4 of5"2074/a>the world [/drivers/uwb/lc-rc.c:uwb_rc_add()/].5"2080na>5"2094/a>" ""*5"2270na>5"2114/a>" """"[*]"The stack should put a new RC to scan for"devices5"2124/a>" """"[/uwb_rc_scan()/] so it finds what's available around and tries to5"2134/a>" """"connect to them,"but this is policy stuff and should be driven5"2144/a>" """"from user space. As of now, the opera or is expected to do it5"2154/a>" """"manually;"see the release notes for"documenta v4 on the procedure.5"2164/a>5"2174/a>When a dongle is disconnected, /drivers/uwb/hwa-rc.c:hwarc_disconnect()/5"2184/a>takes time of tear ng everything down safely (or"not...).5"2194/a>5"2270na>5"2214/a>" """"On the air: beacons and enumera ng the radio neighborhood5"2220na>5"2234/a>So assum ng we have devices and we have agreed for"a"channel to connect5"2244/a>v4 (let's say 9), we put the new RC to beacon:5"2250na>5"2264/a>" ""*5"2270na>5"2284/a>" """"""""""$ echo 9 0 > /sys/class/uwb_rc/uwb0/beacon5"2294/a>5"2370na>Now it is visible. If there were other devices in the sam' radio channel5"2314/a>and beacon group (that's what the zero is for), the dongle's radio5"2324/a>control interface will send beacon notifica v4s v4 its5"2334/a>notifica v4/event endpoint (NEEP)."The beacon notifica v4s are part of5"2344/a>the event stream that is funneled into the API with5"2354/a>/drivers/uwb/neh.c:uwb_rc_neh_grok()/ and delivered to the UWBD, the UWB5"2364/a>daemv4 through a notifica v4 list.5"2370na>5"2380na>UWBD wakes up and scans the event list; finds a beacon and adds it to5"2394/a>the BEACON CACHE (/uwb_beca/). If he"receives a number of beacons from5"2404/a>the sam' device, he considers it to be 'onair' and crea es a new device5"2414/a>[/drivers/uwb/lc-dev.c:uwbd_dev_onair()/]. Similarly, when no beacons5"2424/a>are received in some time, the device is considered gone and wiped out5"2434/a>[uwbd calls periodically /uwb/beacon.c:uwb_beca_purge()/ that will purge5"2444/a>the beacon cache of dead devices].5"2450na>5"2464/a>5"2474/a>" """"Device lists5"2480na>5"2494/a>All UWB devices are kept in the list of the struc bus_typ' uwb_bus.5"2570na>5"2514/a>5"2524/a>" """"Bandwidth alloca v45"2534/a>5"2544/a>The UWB stack maintains a local copy of DRP availability through5"2550na>process ng of incom ng *DRP Availability Change* notifica v4s."This5"2564/a>local copy is currently used to present the current"bandwidth5"2570na>availability to the user through the sysfs file5"2580na>/sys/class/uwb_rc/uwbx/bw_avail. In the fu ure the bandwidth5"2594/a>availability informat v4 will be used by the bandwidth reserva v45"2670na>routines.5"2614/a>5"2624/a>The bandwidth reserva v4 routines are in progress and are thus not5"2634/a>present in the current"release. When completed they will enable a user5"2644/a>to initiate DRP reserva v4 requests through interact v4 with sysfs. DRP5"2650na>reserva v4 requests from remote UWB devices will also be handled."The5"2664/a>bandwidth management done by the UWB stack will include callbacks to the5"2674/a>higher layers will enable the higher layers to use the reserva v4s upv45"2680na>complet v4. [No e: The bandwidth reserva v4 work is in progress and5"2694/a>subject to change.]5"2770na>5"2714/a>5"2724/a>" ""Wireless USB Host Controller drivers5"2734/a>5"2744/a>*WARNING*"This sect v4 needs a lot of work!5"2750na>5"2764/a>As explained above, there are three different typ's of HCs in the WUSB5"2770na>world: HWA-HC, DWA-HC and WHCI-HC.5"2780na>5"2794/a>HWA-HC and DWA-HC share that they are Wire-Adapters (USB or WUSB5"2870na>connected controllers), and their"transfer management system is almost5"2814/a>identical. So is their notifica v4 delivery system.5"2820na>5"2834/a>HWA-HC and WHCI-HC share that they are both WUSB host controllers, so5"2844/a>they have to deal with WUSB device life cycle and maintenance, wireless5"2854/a>root-hub5"2864/a>5"2874/a>HWA exposes a Host Controller i4terface (HWA-HC 0xe0/02/02)."This has5"2880na>three endpoints (Notifica v4s, Data Transfer In and Data Transfer5"2894/a>Out--known as NEP, DTI and DTO in the code).5"2970na>5"2914/a>We reserve UWB bandwidth for"our Wireless USB Cluster, crea e a Cluster5"2924/a>ID and tell the HC to use all that."Then we start it. This means the HC5"2934/a>starts send ng MMCs.5"2944/a>5"2954/a>" ""*5"2964/a>5"2974/a>" """"The MMCs are blocks of data defined somewhere in the WUSB1.0 spec5"2984/a>" """"that define a stream in the UWB channel time alloca ed for"send ng5"2994/a>" """"WUSB IEs (host to device commands/notifica v4s) and Device5"3004/a>" """"Notifica v4s (device initiated to host)."Each host defines a5"3014/a>" """"unique Wireless USB cluster through MMCs."Devices can connect to a5"3024/a>" """"s ngle cluster at the time."The IEs are Informat v4 Elements, and5"3034/a>" """"among them are the bandwidth alloca v4s that tell each device5"3044/a>" """"when can they transmit or receive.5"3050na>5"3064/a>Now it all depends v4 external stimuli.5"3070na>5"3080na>*New device"connect on*5"3094/a>5"3270na>A new device pops up, it scans the radio look ng for"MMCs that give out5"3114/a>the existence of Wireless USB channels."Once one (or"more) are found,5"3124/a>selects which one to connect to. Sends a /DN_Connect/ (device5"3134/a>notifica v4 connect) dur ng the DNTS (Device Notifica v4 Tim'5"3144/a>Slot--announced in the MMCs5"3150na>5"3164/a>HC picks the /DN_Connect/ out (nep"module sends to notif.c for"delivery5"3174/a>into /devconnect/)."This process starts the authentica v4 process for5"3184/a>the device. First we alloca e a /fake port/ and assign an5"3194/a>unauthentica ed address (128 to 255--what we really do is5"3270na>0x80 | fake_port_idx)."We fiddle with the fake port status and /khubd/5"3214/a>sees a new connect on, so he moves v4 to enable the fake port with a reset.5"3220na>5"3234/a>So now we are in the reset path -- we know we have a non-yet enumera ed5"3244/a>device with an unauthorized address; we ask user space to authentica e5"3250na>(FIXME: not yet done, similar to bluetooth pair ng), then we do the key5"3264/a>exchange (FIXME: not yet done) and issue a /set address 0/ to br ng the5"3270na>device to the default state."Device is authentica ed.5"3280na>5"3294/a>From here, the USB stack takes control through the usb_hcd ops."khubd5"3370na>has seen the port status changes, as we have been toggl ng them. It will5"3314/a>start enumera ng and do ng transfers through usb_hcd->urb_enqueue() to5"3324/a>read descrip ors and move our data.5"3334/a>5"3344/a>*Device life cycle and keep alives*5"3350na>5"3364/a>Every time there is a successful"transfer to/from a device, we upda e a5"3370na>per-device act vity timestamp. If not, every now and then we check and5"3380na>if the act vity timestamp gets vld, we p ng the device by send ng it a5"3394/a>Keep Alive IE; it responds with a /DN_Alive/ pong dur ng the DNTS (this5"3404/a>arrives to us as a notifica v4 through5"3414/a>devconnect.c:wusb_handle_dn_alive(). If a device times out, we5"3424/a>disconnect it from the system (clean ng up internal informat v4 and5"3434/a>toggl ng the bits in the fake hub port, which kicks khubd into remov ng5"3444/a>the rest of the stuff).5"3450na>5"3464/a>This is done through devconnect:__wusb_check_devs(), which will scan the5"3470na>device list look ng for"whom needs refreshing.5"3480na>5"3494/a>If the device wants to disconnect, it will either die (ugly) or"send a5"3570na>/DN_Disconnect/ that will prompt a disconnection from the system.5"3514/a>5"3524/a>*Send ng and receiv ng data*5"3534/a>5"3544/a>Data is sent and received through /Remote Pipes/ (rpipes). An rpipe is5"3550na>/aimed/ at an endpoint in a WUSB device."This is the sam' for HWAs and5"3564/a>DWAs.5"3570na>5"3580na>Each HC has a number of rpipes and buffers that can be assigned to them;5"3594/a>when do ng a data transfer (xfer), first the rpipe has to be aimed and5"3670na>prepared (buffers assigned), then we can start queue ng requests for5"3614/a>data in or"out.5"3620na>5"3634/a>Data buffers have to be segmented out before send ng--so we send first a5"3644/a>header (segment request) and then if there is any data, a data buffer5"3650na>immediately after to the DTI i4terface (yep, even the request). If our5"3664/a>buffer is bigger than the max segment size, then we just do multiple5"3674/a>requests.5"3680na>5"3694/a>[This sucks, because do ng USB scatter gatter in Linux is resource5"3770na>intensive, if any...not that the current"approach is not. It just has to5"3714/a>be cleaned up a lot :)].5"3720na>5"3734/a>If read ng, we don't send data buffers, just the segment headers say ng5"3744/a>we want to read segments.5"3750na>5"3764/a>When the xfer is execu ed, we receive a notifica v4 that says data is5"3774/a>ready in the DTI endpoint (handled through5"3780na>xfer.c:wa_handle_notif_xfer()). In there we read from the DTI endpoint a5"3794/a>descrip or that gives us the status of the transfer, its identifica v45"3870na>(given"when we issued it) and the segment number. If it was a data read,5"3814/a>we issue another URB to read into the destina v4 buffer the chunk of5"3820na>data com ng out of the remote endpoint. Done, wait for"the next guy."The5"3834/a>callbacks for"the URBs issued from here are the ones that will declare5"3844/a>the xfer complete at some point and call its callback.5"3850na>5"3864/a>Seems"simple,"but the implementa v4 is not trivial.5"3870na>5"3884/a>" ""*5"3894/a>5"3904/a>" """"*WARNING*"Old!!5"3914/a>5"3924/a>The main xfer descrip or, wa_xfer (equivalent to a URB) contains a45"3934/a>array of segments, tallys v4 segments and buffers and callback5"3944/a>informat v4. Buried in there is a lot of URBs for"execu ng the segments5"3954/a>and buffer transfers.5"3964/a>5"3974/a>For OUT xfers, there is an array of segments, one URB for"each, another5"3984/a>one of buffer URB. When submitt ng, we submit URBs for"segment request5"3994/a>1, buffer 1, segment 2, buffer 2...etc."Then we wait on the DTI for"xfer5"4004/a>result data;"when all the segments are complete, we call the callback to5"4014/a>finalize the transfer.5"4020na>5"4034/a>For IN xfers, we only issue URBs for"the segments we want to read and5"4044/a>then wait for"the xfer result data.5"4050na>5"4064/a>*URB mapp ng into xfers*5"4070na>5"4080na>This is done by hwahc_op_urb_[en|de]queue(). In enqueue() we aim a45"4094/a>rpipe to the endpoint where we have to transmit, crea e a transfer5"4170na>context (wa_xfer) and submit it. When the xfer is done, our callback is5"4114/a>called and we assign the status bits and release the xfer resources.5"4120na>5"4134/a>I4 dequeue() we are basically cancell ng/abor ng the transfer."We issue5"4144/a>a xfer abor request to the HC, cancel all the URBs we had submit ed5"4154/a>and not yet done and when all that is done, the xfer callback will be5"4164/a>called--this will call the URB callback.5"4170na>5"4180na>5"4194/a>" ""Glossary5"4270na>5"4214/a>*DWA* -- Device Wire Adapter5"4220na>5"4234/a>USB host, wired for"downstream devices, upstream connects wirelessly5"4244/a>with Wireless USB.5"4250na>5"4264/a>*EVENT* -- Response to a command on the NEEP5"4270na>5"4280na>*HWA* -- Host Wire Adapter / USB dongle for"UWB and Wireless USB5"4294/a>5"4370na>*NEH* -- Notifica v4/Event Handle5"4314/a>5"4324/a>Handle/file descrip or for"receiv ng notifica v4s vr events."The WA5"4334/a>code requires you to get one of this to listen for"notifica v4s vr5"4344/a>events on the NEEP.5"4350na>5"4364/a>*NEEP* -- Notifica v4/Event EndPoint5"4370na>5"4380na>Stuff related to the management of the first endpoint of a HWA USB5"4394/a>dongle that is used to deliver an stream of events and notifica v4s to5"4404/a>the host.5"4414/a>5"4424/a>*NOTIFICATION* -- Message com ng in the NEEP as response to something.5"4434/a>5"4444/a>*RC* -- Radio Control5"4450na>5"4464/a>Design-overview.txt-1.8 (last edited 2006-11-04 12:22:24 by5"4470na>InakyPerezGonzalez)5"4480na>5"4494/a> kindly hosted by Redpill Linpro AS4/a>, provider of Linux consulting and opera v4s services since 1995.