lincan-0.3.3/doc/lincandoc/lincan/lincan_history.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <section id="lincan_history">
   3   <title>Driver History and Implementation Issues</title>
   4
   5   <para>The development of the CAN drivers for Linux has long history.
   6   We have been faced before two basic alternatives, start new project
   7   from scratch or use some other project as basis of our development.
   8   The first approach could lead faster to more simple and clean
   9   internal architecture but it would mean to introduce new driver with
  10   probably incompatible interface unusable for already existing
  11   applications. The support of many types of cards is thing which takes
  12   long time as well. More existing projects aimed to development of
  13   a Linux CAN driver has been analyzed:</para>
  14
  15   <variablelist>
  16     <varlistentry>
  17       <term>Original LDDK CAN driver project</term>
  18
  19       <listitem>
  20         <para>The driver project aborted on the kernel evolution and LDDK
  21         concept. The LDDK tried to prepare infrastructure for
  22         development of the kernel version independent character device
  23         drivers written in meta code. The goal was top-ranking, but it
  24         proves, that well written &#34;C&#34; language driver can be
  25         more portable than the LDDK complex infrastructure.</para>
  26       </listitem>
  27     </varlistentry>
  28
  29     <varlistentry>
  30       <term>can4linux-0.9 by PORT GmbH</term>
  31
  32       <listitem>
  33         <para>This is version of the above LDDK driver maintained by Port
  34         GmbH. The card type is hard compiled into the driver by selected
  35         defines and only Philips 82c200 chips are supported.</para>
  36       </listitem>
  37     </varlistentry>
  38
  39     <varlistentry>
  40       <term>CanFestival</term>
  41
  42       <listitem>
  43         <para>The big advantage of this driver is an integrated support for
  44         the RT-Linux, but driver implementation is highly coupled to one
  45         card. Some concepts of the driver are interesting but the driver has
  46         the hard-coded number of message queues.</para>
  47       </listitem>
  48     </varlistentry>
  49
  50     <varlistentry>
  51       <term>can-0.7.1 by Arnaud Westenberg</term>
  52
  53       <listitem>
  54         <para>This driver has its roots in the LDDK project as well. The
  55         original LDDK concept has been eliminated in the driver source
  56         and necessary adaptation of the driver for the different Linux kernel
  57         versions is achieved by the controllable number of defines and
  58         conditional compilation. There is more independent contributors.
  59         The main advantages of the driver are support of many cards working
  60         in parallel, IO and memory space chip connection support and more
  61         cards of different types can be selected at module load time.
  62         There exist more users and applications compatible with the driver
  63         interface. Disadvantages of the original version of this driver are
  64         non-optimal infrastructure, non-portable make system and lack of the
  65         select support.</para>
  66       </listitem>
  67     </varlistentry>
  68   </variablelist>
  69
  70   <para>The responsible OCERA developers selected the
  71   <interfacename>can-0.7.1</interfacename> driver as a base of their
  72   development for next reasons:</para>
  73
  74   <itemizedlist>
  75     <listitem>
  76       <para>Best support for more cards in system</para>
  77     </listitem>
  78
  79     <listitem>
  80       <para>Supports for many types of cards</para>
  81     </listitem>
  82
  83     <listitem>
  84       <para>The internal abstraction of the peripheral access method and
  85       the chip support</para>
  86     </listitem>
  87   </itemizedlist>
  88
  89   <para>The most important features added by OCERA
  90   development team are:</para>
  91
  92   <itemizedlist>
  93     <listitem>
  94       <para>Added the select system call support</para>
  95     </listitem>
  96
  97     <listitem>
  98       <para>The support for our memory mapped ISA card added, which proved
  99       simplicity of addition of the support for new type of CAN cards</para>
 100     </listitem>
 101
 102     <listitem>
 103       <para>Added devfs support</para>
 104     </listitem>
 105
 106     <listitem>
 107       <para>Revised and bug-fixed the IRQ support in the first phase</para>
 108     </listitem>
 109
 110     <listitem>
 111       <para>Added support for 2.6.x kernels</para>
 112     </listitem>
 113
 114     <listitem>
 115       <para>Rebuilt the make system to compile options fully follow the running
 116       kernel options, cross-compilation still possible when the kernel
 117       location and compiler is specified. The driver checked with more 2.2.x,
 118       2.4.x and 2.6.x kernels and hardware configurations.</para>
 119     </listitem>
 120
 121     <listitem>
 122       <para>Cleaned-up synchronization required to support 2.6.x SMP kernels
 123       and enhanced 2.4.x kernels performance</para>
 124     </listitem>
 125
 126     <listitem>
 127       <para>The deeper rebuilt of the driver infrastructure to enable porting to
 128       more systems (most important RT-Linux). The naive FIFO implementation
 129       has been replaced by robust CAN queues, edges and ends framework.
 130       The big advantage of continuous development is ability to keep compatibility
 131       with many cards and applications</para>
 132     </listitem>
 133
 134     <listitem>
 135       <para>The infrastructure rewrite enabled to support multiple opening
 136       of the single minor device</para>
 137     </listitem>
 138
 139     <listitem>
 140       <para>Support for individual queues message acceptance filters added</para>
 141     </listitem>
 142
 143     <listitem>
 144       <para>The driver setup functions modified to enable PCI and USB hardware
 145       hot-swapping and PnP recognition in the future</para>
 146     </listitem>
 147
 148     <listitem>
 149       <para>Added support for KVASER PCI cards family</para>
 150     </listitem>
 151
 152     <listitem>
 153       <para>Added support for virtual can board for more CAN/CANopen components interworking
 154       testing on single computer without real CAN hardware.</para>
 155     </listitem>
 156
 157     <listitem>
 158       <para>The conditional compilation mode for Linux/RT-Linux support has been added.
 159       The driver manipulates with chips and boards from RT-Linux hard real-time
 160       worker threads in that compilation mode. The POSIX device file interface
 161       is provided for RT-Linux threads in parallel to the standard Linux
 162       device interface.</para>
 163     </listitem>
 164
 165     <listitem>
 166       <para>Work on support for first of intelligent CAN/CANopen cards has
 167       been started</para>
 168     </listitem>
 169   </itemizedlist>
 170
 171   <para>The possible future enhancements</para>
 172
 173   <itemizedlist>
 174     <listitem>
 175       <para>Cleanup and enhance RTR processing. Add some support for
 176       emulated RTR processing for SJA1000 chips</para>
 177     </listitem>
 178
 179     <listitem>
 180       <para>Enhance clients API to gain full advantages of possibility
 181       to connect more CAN queues with different priorities
 182       to the one user state structure</para>
 183     </listitem>
 184
 185     <listitem>
 186       <para>Add support for more CAN cards and chips (82C900 comes to mind)</para>
 187     </listitem>
 188
 189     <listitem>
 190       <para>Add support for XILINX FPGA based board in development at CTU.
 191       There already exists VHDL source for the chip core, connect it
 192       to PC-104 bus and LinCAN driver</para>
 193     </listitem>
 194
 195     <listitem>
 196       <para>Do next steps in the PCI cards support cleanup and add Linux 2.6.x
 197       sysfs support</para>
 198     </listitem>
 199   </itemizedlist>
 200
 201 </section>
 202