remove outdated files, improve documentation slightly.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@2664 c6295689-39f2-0310-b995-f0e70906c6a9
This commit is contained in:
parent
90d1b0cc9c
commit
9d549e6aba
217
CodingStyle
217
CodingStyle
|
@ -1,217 +0,0 @@
|
||||||
|
|
||||||
This is ripped from the Linux kernel tarball, but applies also to
|
|
||||||
the OpenSC project.
|
|
||||||
|
|
||||||
Linux kernel coding style
|
|
||||||
|
|
||||||
This is a short document describing the preferred coding style for the
|
|
||||||
linux kernel. Coding style is very personal, and I won't _force_ my
|
|
||||||
views on anybody, but this is what goes for anything that I have to be
|
|
||||||
able to maintain, and I'd prefer it for most other things too. Please
|
|
||||||
at least consider the points made here.
|
|
||||||
|
|
||||||
First off, I'd suggest printing out a copy of the GNU coding standards,
|
|
||||||
and NOT read it. Burn them, it's a great symbolic gesture.
|
|
||||||
|
|
||||||
Anyway, here goes:
|
|
||||||
|
|
||||||
|
|
||||||
Chapter 1: Indentation
|
|
||||||
|
|
||||||
Tabs are 8 characters, and thus indentations are also 8 characters.
|
|
||||||
There are heretic movements that try to make indentations 4 (or even 2!)
|
|
||||||
characters deep, and that is akin to trying to define the value of PI to
|
|
||||||
be 3.
|
|
||||||
|
|
||||||
Rationale: The whole idea behind indentation is to clearly define where
|
|
||||||
a block of control starts and ends. Especially when you've been looking
|
|
||||||
at your screen for 20 straight hours, you'll find it a lot easier to see
|
|
||||||
how the indentation works if you have large indentations.
|
|
||||||
|
|
||||||
Now, some people will claim that having 8-character indentations makes
|
|
||||||
the code move too far to the right, and makes it hard to read on a
|
|
||||||
80-character terminal screen. The answer to that is that if you need
|
|
||||||
more than 3 levels of indentation, you're screwed anyway, and should fix
|
|
||||||
your program.
|
|
||||||
|
|
||||||
In short, 8-char indents make things easier to read, and have the added
|
|
||||||
benefit of warning you when you're nesting your functions too deep.
|
|
||||||
Heed that warning.
|
|
||||||
|
|
||||||
|
|
||||||
Chapter 2: Placing Braces
|
|
||||||
|
|
||||||
The other issue that always comes up in C styling is the placement of
|
|
||||||
braces. Unlike the indent size, there are few technical reasons to
|
|
||||||
choose one placement strategy over the other, but the preferred way, as
|
|
||||||
shown to us by the prophets Kernighan and Ritchie, is to put the opening
|
|
||||||
brace last on the line, and put the closing brace first, thusly:
|
|
||||||
|
|
||||||
if (x is true) {
|
|
||||||
we do y
|
|
||||||
}
|
|
||||||
|
|
||||||
However, there is one special case, namely functions: they have the
|
|
||||||
opening brace at the beginning of the next line, thus:
|
|
||||||
|
|
||||||
int function(int x)
|
|
||||||
{
|
|
||||||
body of function
|
|
||||||
}
|
|
||||||
|
|
||||||
Heretic people all over the world have claimed that this inconsistency
|
|
||||||
is ... well ... inconsistent, but all right-thinking people know that
|
|
||||||
(a) K&R are _right_ and (b) K&R are right. Besides, functions are
|
|
||||||
special anyway (you can't nest them in C).
|
|
||||||
|
|
||||||
Note that the closing brace is empty on a line of its own, _except_ in
|
|
||||||
the cases where it is followed by a continuation of the same statement,
|
|
||||||
ie a "while" in a do-statement or an "else" in an if-statement, like
|
|
||||||
this:
|
|
||||||
|
|
||||||
do {
|
|
||||||
body of do-loop
|
|
||||||
} while (condition);
|
|
||||||
|
|
||||||
and
|
|
||||||
|
|
||||||
if (x == y) {
|
|
||||||
..
|
|
||||||
} else if (x > y) {
|
|
||||||
...
|
|
||||||
} else {
|
|
||||||
....
|
|
||||||
}
|
|
||||||
|
|
||||||
Rationale: K&R.
|
|
||||||
|
|
||||||
Also, note that this brace-placement also minimizes the number of empty
|
|
||||||
(or almost empty) lines, without any loss of readability. Thus, as the
|
|
||||||
supply of new-lines on your screen is not a renewable resource (think
|
|
||||||
25-line terminal screens here), you have more empty lines to put
|
|
||||||
comments on.
|
|
||||||
|
|
||||||
|
|
||||||
Chapter 3: Naming
|
|
||||||
|
|
||||||
C is a Spartan language, and so should your naming be. Unlike Modula-2
|
|
||||||
and Pascal programmers, C programmers do not use cute names like
|
|
||||||
ThisVariableIsATemporaryCounter. A C programmer would call that
|
|
||||||
variable "tmp", which is much easier to write, and not the least more
|
|
||||||
difficult to understand.
|
|
||||||
|
|
||||||
HOWEVER, while mixed-case names are frowned upon, descriptive names for
|
|
||||||
global variables are a must. To call a global function "foo" is a
|
|
||||||
shooting offense.
|
|
||||||
|
|
||||||
GLOBAL variables (to be used only if you _really_ need them) need to
|
|
||||||
have descriptive names, as do global functions. If you have a function
|
|
||||||
that counts the number of active users, you should call that
|
|
||||||
"count_active_users()" or similar, you should _not_ call it "cntusr()".
|
|
||||||
|
|
||||||
Encoding the type of a function into the name (so-called Hungarian
|
|
||||||
notation) is brain damaged - the compiler knows the types anyway and can
|
|
||||||
check those, and it only confuses the programmer. No wonder MicroSoft
|
|
||||||
makes buggy programs.
|
|
||||||
|
|
||||||
LOCAL variable names should be short, and to the point. If you have
|
|
||||||
some random integer loop counter, it should probably be called "i".
|
|
||||||
Calling it "loop_counter" is non-productive, if there is no chance of it
|
|
||||||
being mis-understood. Similarly, "tmp" can be just about any type of
|
|
||||||
variable that is used to hold a temporary value.
|
|
||||||
|
|
||||||
If you are afraid to mix up your local variable names, you have another
|
|
||||||
problem, which is called the function-growth-hormone-imbalance syndrome.
|
|
||||||
See next chapter.
|
|
||||||
|
|
||||||
|
|
||||||
Chapter 4: Functions
|
|
||||||
|
|
||||||
Functions should be short and sweet, and do just one thing. They should
|
|
||||||
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
|
|
||||||
as we all know), and do one thing and do that well.
|
|
||||||
|
|
||||||
The maximum length of a function is inversely proportional to the
|
|
||||||
complexity and indentation level of that function. So, if you have a
|
|
||||||
conceptually simple function that is just one long (but simple)
|
|
||||||
case-statement, where you have to do lots of small things for a lot of
|
|
||||||
different cases, it's OK to have a longer function.
|
|
||||||
|
|
||||||
However, if you have a complex function, and you suspect that a
|
|
||||||
less-than-gifted first-year high-school student might not even
|
|
||||||
understand what the function is all about, you should adhere to the
|
|
||||||
maximum limits all the more closely. Use helper functions with
|
|
||||||
descriptive names (you can ask the compiler to in-line them if you think
|
|
||||||
it's performance-critical, and it will probably do a better job of it
|
|
||||||
that you would have done).
|
|
||||||
|
|
||||||
Another measure of the function is the number of local variables. They
|
|
||||||
shouldn't exceed 5-10, or you're doing something wrong. Re-think the
|
|
||||||
function, and split it into smaller pieces. A human brain can
|
|
||||||
generally easily keep track of about 7 different things, anything more
|
|
||||||
and it gets confused. You know you're brilliant, but maybe you'd like
|
|
||||||
to understand what you did 2 weeks from now.
|
|
||||||
|
|
||||||
|
|
||||||
Chapter 5: Commenting
|
|
||||||
|
|
||||||
Comments are good, but there is also a danger of over-commenting. NEVER
|
|
||||||
try to explain HOW your code works in a comment: it's much better to
|
|
||||||
write the code so that the _working_ is obvious, and it's a waste of
|
|
||||||
time to explain badly written code.
|
|
||||||
|
|
||||||
Generally, you want your comments to tell WHAT your code does, not HOW.
|
|
||||||
Also, try to avoid putting comments inside a function body: if the
|
|
||||||
function is so complex that you need to separately comment parts of it,
|
|
||||||
you should probably go back to chapter 4 for a while. You can make
|
|
||||||
small comments to note or warn about something particularly clever (or
|
|
||||||
ugly), but try to avoid excess. Instead, put the comments at the head
|
|
||||||
of the function, telling people what it does, and possibly WHY it does
|
|
||||||
it.
|
|
||||||
|
|
||||||
|
|
||||||
Chapter 6: You've made a mess of it
|
|
||||||
|
|
||||||
That's OK, we all do. You've probably been told by your long-time Unix
|
|
||||||
user helper that "GNU emacs" automatically formats the C sources for
|
|
||||||
you, and you've noticed that yes, it does do that, but the defaults it
|
|
||||||
uses are less than desirable (in fact, they are worse than random
|
|
||||||
typing - a infinite number of monkeys typing into GNU emacs would never
|
|
||||||
make a good program).
|
|
||||||
|
|
||||||
So, you can either get rid of GNU emacs, or change it to use saner
|
|
||||||
values. To do the latter, you can stick the following in your .emacs file:
|
|
||||||
|
|
||||||
(defun linux-c-mode ()
|
|
||||||
"C mode with adjusted defaults for use with the Linux kernel."
|
|
||||||
(interactive)
|
|
||||||
(c-mode)
|
|
||||||
(c-set-style "K&R")
|
|
||||||
(setq c-basic-offset 8))
|
|
||||||
|
|
||||||
This will define the M-x linux-c-mode command. When hacking on a
|
|
||||||
module, if you put the string -*- linux-c -*- somewhere on the first
|
|
||||||
two lines, this mode will be automatically invoked. Also, you may want
|
|
||||||
to add
|
|
||||||
|
|
||||||
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
|
|
||||||
auto-mode-alist))
|
|
||||||
|
|
||||||
to your .emacs file if you want to have linux-c-mode switched on
|
|
||||||
automagically when you edit source files under /usr/src/linux.
|
|
||||||
|
|
||||||
But even if you fail in getting emacs to do sane formatting, not
|
|
||||||
everything is lost: use "indent".
|
|
||||||
|
|
||||||
Now, again, GNU indent has the same brain dead settings that GNU emacs
|
|
||||||
has, which is why you need to give it a few command line options.
|
|
||||||
However, that's not too bad, because even the makers of GNU indent
|
|
||||||
recognize the authority of K&R (the GNU people aren't evil, they are
|
|
||||||
just severely misguided in this matter), so you just give indent the
|
|
||||||
options "-kr -i8" (stands for "K&R, 8 character indents").
|
|
||||||
|
|
||||||
"indent" has a lot of options, and especially when it comes to comment
|
|
||||||
re-formatting you may want to take a look at the manual page. But
|
|
||||||
remember: "indent" is not a fix for bad programming.
|
|
||||||
|
|
||||||
|
|
190
INSTALL
190
INSTALL
|
@ -1,190 +0,0 @@
|
||||||
Basic Installation
|
|
||||||
==================
|
|
||||||
|
|
||||||
These are generic installation instructions.
|
|
||||||
|
|
||||||
The `configure' shell script attempts to guess correct values for
|
|
||||||
various system-dependent variables used during compilation. It uses
|
|
||||||
those values to create a `Makefile' in each directory of the package.
|
|
||||||
It may also create one or more `.h' files containing system-dependent
|
|
||||||
definitions. Finally, it creates a shell script `config.status' that
|
|
||||||
you can run in the future to recreate the current configuration, a file
|
|
||||||
`config.cache' that saves the results of its tests to speed up
|
|
||||||
reconfiguring, and a file `config.log' containing compiler output
|
|
||||||
(useful mainly for debugging `configure').
|
|
||||||
|
|
||||||
If you need to do unusual things to compile the package, please try
|
|
||||||
to figure out how `configure' could check whether to do them, and mail
|
|
||||||
diffs or instructions to the address given in the `README' so they can
|
|
||||||
be considered for the next release. If at some point `config.cache'
|
|
||||||
contains results you don't want to keep, you may remove or edit it.
|
|
||||||
|
|
||||||
The file `configure.in' is used to create `configure' by a program
|
|
||||||
called `autoconf'. You only need `configure.in' if you want to change
|
|
||||||
it or regenerate `configure' using a newer version of `autoconf'.
|
|
||||||
|
|
||||||
The simplest way to compile this package is:
|
|
||||||
|
|
||||||
1. `cd' to the directory containing the package's source code and type
|
|
||||||
`./configure' to configure the package for your system. If you're
|
|
||||||
using `csh' on an old version of System V, you might need to type
|
|
||||||
`sh ./configure' instead to prevent `csh' from trying to execute
|
|
||||||
`configure' itself.
|
|
||||||
|
|
||||||
Running `configure' takes awhile. While running, it prints some
|
|
||||||
messages telling which features it is checking for.
|
|
||||||
|
|
||||||
2. Type `make' to compile the package.
|
|
||||||
|
|
||||||
3. Optionally, type `make check' to run any self-tests that come with
|
|
||||||
the package.
|
|
||||||
|
|
||||||
4. Type `make install' to install the programs and any data files and
|
|
||||||
documentation.
|
|
||||||
|
|
||||||
5. You can remove the program binaries and object files from the
|
|
||||||
source code directory by typing `make clean'. To also remove the
|
|
||||||
files that `configure' created (so you can compile the package for
|
|
||||||
a different kind of computer), type `make distclean'. There is
|
|
||||||
also a `make maintainer-clean' target, but that is intended mainly
|
|
||||||
for the package's developers. If you use it, you may have to get
|
|
||||||
all sorts of other programs in order to regenerate files that came
|
|
||||||
with the distribution.
|
|
||||||
|
|
||||||
Compilers and Options
|
|
||||||
=====================
|
|
||||||
|
|
||||||
Some systems require unusual options for compilation or linking that
|
|
||||||
the `configure' script does not know about. You can give `configure'
|
|
||||||
initial values for variables by setting them in the environment. Using
|
|
||||||
a Bourne-compatible shell, you can do that on the command line like
|
|
||||||
this:
|
|
||||||
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
|
|
||||||
|
|
||||||
Or on systems that have the `env' program, you can do it like this:
|
|
||||||
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
|
|
||||||
|
|
||||||
Compiling For Multiple Architectures
|
|
||||||
====================================
|
|
||||||
|
|
||||||
You can compile the package for more than one kind of computer at the
|
|
||||||
same time, by placing the object files for each architecture in their
|
|
||||||
own directory. To do this, you must use a version of `make' that
|
|
||||||
supports the `VPATH' variable, such as GNU `make'. `cd' to the
|
|
||||||
directory where you want the object files and executables to go and run
|
|
||||||
the `configure' script. `configure' automatically checks for the
|
|
||||||
source code in the directory that `configure' is in and in `..'.
|
|
||||||
|
|
||||||
If you have to use a `make' that does not supports the `VPATH'
|
|
||||||
variable, you have to compile the package for one architecture at a time
|
|
||||||
in the source code directory. After you have installed the package for
|
|
||||||
one architecture, use `make distclean' before reconfiguring for another
|
|
||||||
architecture.
|
|
||||||
|
|
||||||
Installation Names
|
|
||||||
==================
|
|
||||||
|
|
||||||
By default, `make install' will install the package's files in
|
|
||||||
`/usr/local/bin', `/usr/local/man', etc. You can specify an
|
|
||||||
installation prefix other than `/usr/local' by giving `configure' the
|
|
||||||
option `--prefix=PATH'.
|
|
||||||
|
|
||||||
You can specify separate installation prefixes for
|
|
||||||
architecture-specific files and architecture-independent files. If you
|
|
||||||
give `configure' the option `--exec-prefix=PATH', the package will use
|
|
||||||
PATH as the prefix for installing programs and libraries.
|
|
||||||
Documentation and other data files will still use the regular prefix.
|
|
||||||
|
|
||||||
In addition, if you use an unusual directory layout you can give
|
|
||||||
options like `--bindir=PATH' to specify different values for particular
|
|
||||||
kinds of files. Run `configure --help' for a list of the directories
|
|
||||||
you can set and what kinds of files go in them.
|
|
||||||
|
|
||||||
If the package supports it, you can cause programs to be installed
|
|
||||||
with an extra prefix or suffix on their names by giving `configure' the
|
|
||||||
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
|
|
||||||
|
|
||||||
Optional Features
|
|
||||||
=================
|
|
||||||
|
|
||||||
Some packages pay attention to `--enable-FEATURE' options to
|
|
||||||
`configure', where FEATURE indicates an optional part of the package.
|
|
||||||
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
|
|
||||||
is something like `gnu-as' or `x' (for the X Window System). The
|
|
||||||
`README' should mention any `--enable-' and `--with-' options that the
|
|
||||||
package recognizes.
|
|
||||||
|
|
||||||
For packages that use the X Window System, `configure' can usually
|
|
||||||
find the X include and library files automatically, but if it doesn't,
|
|
||||||
you can use the `configure' options `--x-includes=DIR' and
|
|
||||||
`--x-libraries=DIR' to specify their locations.
|
|
||||||
|
|
||||||
Specifying the System Type
|
|
||||||
==========================
|
|
||||||
|
|
||||||
There may be some features `configure' can not figure out
|
|
||||||
automatically, but needs to determine by the type of host the package
|
|
||||||
will run on. Usually `configure' can figure that out, but if it prints
|
|
||||||
a message saying it can not guess the host type, give it the
|
|
||||||
`--host=TYPE' option. TYPE can either be a short name for the system
|
|
||||||
type, such as `sun4', or a canonical name with three fields:
|
|
||||||
CPU-COMPANY-SYSTEM
|
|
||||||
|
|
||||||
See the file `config.sub' for the possible values of each field. If
|
|
||||||
`config.sub' isn't included in this package, then this package doesn't
|
|
||||||
need to know the host type.
|
|
||||||
|
|
||||||
If you are building compiler tools for cross-compiling, you can also
|
|
||||||
use the `--target=TYPE' option to select the type of system they will
|
|
||||||
produce code for and the `--build=TYPE' option to select the type of
|
|
||||||
system on which you are compiling the package.
|
|
||||||
|
|
||||||
Sharing Defaults
|
|
||||||
================
|
|
||||||
|
|
||||||
If you want to set default values for `configure' scripts to share,
|
|
||||||
you can create a site shell script called `config.site' that gives
|
|
||||||
default values for variables like `CC', `cache_file', and `prefix'.
|
|
||||||
`configure' looks for `PREFIX/share/config.site' if it exists, then
|
|
||||||
`PREFIX/etc/config.site' if it exists. Or, you can set the
|
|
||||||
`CONFIG_SITE' environment variable to the location of the site script.
|
|
||||||
A warning: not all `configure' scripts look for a site script.
|
|
||||||
|
|
||||||
Operation Controls
|
|
||||||
==================
|
|
||||||
|
|
||||||
`configure' recognizes the following options to control how it
|
|
||||||
operates.
|
|
||||||
|
|
||||||
`--cache-file=FILE'
|
|
||||||
Use and save the results of the tests in FILE instead of
|
|
||||||
`./config.cache'. Set FILE to `/dev/null' to disable caching, for
|
|
||||||
debugging `configure'.
|
|
||||||
|
|
||||||
`--help'
|
|
||||||
Print a summary of the options to `configure', and exit.
|
|
||||||
|
|
||||||
`--quiet'
|
|
||||||
`--silent'
|
|
||||||
`-q'
|
|
||||||
Do not print messages saying which checks are being made. To
|
|
||||||
suppress all normal output, redirect it to `/dev/null' (any error
|
|
||||||
messages will still be shown).
|
|
||||||
|
|
||||||
`--srcdir=DIR'
|
|
||||||
Look for the package's source code in directory DIR. Usually
|
|
||||||
`configure' can determine that directory automatically.
|
|
||||||
|
|
||||||
`--version'
|
|
||||||
Print the version of Autoconf used to generate the `configure'
|
|
||||||
script, and exit.
|
|
||||||
|
|
||||||
`configure' also accepts some other, not widely useful, options.
|
|
||||||
|
|
||||||
Windows
|
|
||||||
=======
|
|
||||||
|
|
||||||
If you have Cygwin or Mingw installed (with the necessary packages/libs),
|
|
||||||
you should be able to follow the above instructions.
|
|
||||||
If you use the MS compiler, you should also install perl. And you have
|
|
||||||
to follow the instruction in win32\Makes.rules.mak and edit this file.
|
|
|
@ -3,7 +3,7 @@
|
||||||
SUBDIRS = . aclocal etc man src win32
|
SUBDIRS = . aclocal etc man src win32
|
||||||
DIST_SUBDIRS = . aclocal doc etc man src win32
|
DIST_SUBDIRS = . aclocal doc etc man src win32
|
||||||
|
|
||||||
EXTRA_DIST = CodingStyle README \
|
EXTRA_DIST = README \
|
||||||
bootstrap Makefile.mak depcomp \
|
bootstrap Makefile.mak depcomp \
|
||||||
solaris/Makefile solaris/README solaris/checkinstall.in \
|
solaris/Makefile solaris/README solaris/checkinstall.in \
|
||||||
solaris/opensc.conf-dist solaris/pkginfo.in solaris/proto
|
solaris/opensc.conf-dist solaris/pkginfo.in solaris/proto
|
||||||
|
|
3
NEWS
3
NEWS
|
@ -6,7 +6,8 @@ http://www.opensc.org/opensc/wiki/WhatsNew
|
||||||
Also see the svn changelog using svn command
|
Also see the svn changelog using svn command
|
||||||
or doc/ChangeLog.
|
or doc/ChangeLog.
|
||||||
|
|
||||||
New in 0.10.0-rc1; Andreas Jellinghaus
|
New in 0.10.0-rc2; 2005-10-24; Andreas Jellinghaus
|
||||||
|
* Add more documentation, fix man page installtion.
|
||||||
* New generic ATR/card matching code with
|
* New generic ATR/card matching code with
|
||||||
atrmask support, used by all card drivers.
|
atrmask support, used by all card drivers.
|
||||||
* Much improved and unified ATR handling in
|
* Much improved and unified ATR handling in
|
||||||
|
|
7
README
7
README
|
@ -11,6 +11,13 @@ A short introduction what OpenSC is and how it fits into the big picture.
|
||||||
|
|
||||||
WhatsNew
|
WhatsNew
|
||||||
What is new, what has changed since the last major release?
|
What is new, what has changed since the last major release?
|
||||||
|
Also see this section for a list of incompatibilities.
|
||||||
|
|
||||||
|
Short list: libopensc is now version 2.0.0, i.e. you need to
|
||||||
|
recompile applications using opensc. And all libraries and
|
||||||
|
the opensc-pkcs11.so module moved from lib/pkcs11/ or lib/opensc/
|
||||||
|
to simply lib/. That fixes a number of problems, but you might
|
||||||
|
need to change some configuration.
|
||||||
|
|
||||||
OperatingSystems
|
OperatingSystems
|
||||||
What your operating system needs to have for OpenSC to work.
|
What your operating system needs to have for OpenSC to work.
|
||||||
|
|
Loading…
Reference in New Issue