SEC 2.0 Reference Device Driver User’s Guide, Rev. 0
40
PRELIMINARY—SUBJECT TO CHANGE WITHOUT NOTICE
Freescale Semiconductor
VxWorks Environment
6.2.2 Driver Operation in User Mode
Operation of the SEC2 device in user mode is slightly more complex than in kernel mode. In particular, the transition
from user to kernel memory space creates two complications for user mode operation:
1.
User memory buffers can't be passed directly to the driver; instead, in this driver edition, the user must
allocate and place data in kernel memory buffer for operation. This can be accomplished via
SEC2_MALLOC
,
SEC2_FREE
,
SEC2_COPYFROM
, and
SEC2_COPYTO
requests (see
Section 3.3.1, “I/O Control Codes”
for
more information).
Note: extreme caution must be exercised by the user in transferring memory in this fashion; kernel memory
space may easily be corrupted by the caller, causing target system instability.
2.
Standard notification callbacks cannot work, since the routines to perform the callback are in user memory
space, and cannot safely execute from kernel mode. In their place, standard POSIX signals can be used to
indicate I/O completion by placing the process ID of the user task in the notification members of the
request, and flagging
NOTIFY_IS_PID
in the
notifyFlags
member. The driver uses
SIGUSR1
to
indicate normal request completions, and
SIGUSR2
to indicate error completions.
The example suite available with the driver illustrates the contrast between the two different application
environments. Within the
testAll.c
file, there is a set of functions that shows the difference between the two
operations. Building the example testing application with
__KERNEL__
on (building a kernel mode test) shows the
installation and usage of standard completion callbacks and a mutex used for interlock. Conversely, building the
example testing application with
USERMODE
turned on shows the installation of signal handlers and their proper
setup.
In
USERMODE
, this example also shows one possible means for handling the user to kernel memory transition via the
use of three functions for transferring user buffers to and from kernel memory.
6.2.3 Driver Module License Macro
A common necessity of loadable modules for Linux is the inclusion of a license macro (MODULE_LICENSE) that
declares a string defining the type of license terms under which the module's code has been published. In the case
of the SEC2 driver module, this code is delivered in source form under the terms of a restricted license agreement.
Therefore, this macro has been passed a name of “Freescale Restricted” to acknowledge the existence of this
agreement.
When loading the driver object, the existence of a non-GPL, non-BSD license string will cause a warning message
to be printed to the console, stating that loading a module with a proprietary license will “taint” the kernel. This
message is normal, expected, and will not cause any adverse operation of your running system.
7
VxWorks Environment
The following sections describe the installation of the SEC2 security processor software drivers, BSP integration,
and distribution archives.
7.1 Installation
To install the software drivers, extract the archive containing the driver source files into a suitable installation
directory. If you want the driver and tests to be part of a standard VxWorks source tree, place them in:
