Quoting the errno manual:
"[errno] is set by system calls and some library functions in the
event of an error to indicate what went wrong. Its value is
significant only when the return value of the call indicated an
error (i.e., -1 from most system calls; -1 or NULL from most library
functions); a function that succeeds is allowed to change errno.
Valid error numbers are all nonzero; errno is never set to zero by
any system call or library function."
Dumpiso and sendiso checked for raw1394_set_port() failure by
looking at errno rather than by looking at the function's return
code. This happened to work on top of raw1394 by lucky incident but
no longer works on top of firewire-core.
Reported-by: Vladimir Romanov <blueboar2@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Testlibraw always showed the name of the first card rather than the
name of the current card.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This lets initiators of isochronous streams or asynchronous streams from
or to the local node figure out what maximum speed can be configured.
Furthermore it can be used to display connection speeds for informative
purposes without having to perform topology analysis (in case of 1394a
buses) or extensive phy port status queries (in case of 1394b buses).
To be in line with other existing libraw1394 APIs which use nodeid_t
variables, this API identifies a node only via a card:nodeID tuple which
is unsafe against generation changes. A node can only be properly
identified by card:generation:nodeID tuples. However, since this new
API extension and libraw1394 as a whole is mainly aimed towards existing
libraw1394 client code bases rather than new developments, I decided
against making this call race free but somewhat more difficult to use in
typical existing client code.
A unit test for the new call is added to testlibraw as well.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This is an extension relative to raw1394_read_cycle_timer().
It lets the client choose a system clock other than CLOCK_REALTIME.
Use case: http://subversion.ffado.org/ticket/242
The underlying ioctl supports reading the system clock with nanoseconds
resolution. The new libraw1394 call sticks with microseconds resolution
though. This makes transition from (or parallel use with)
raw1394_read_cycle_timer() easier. Besides, the call itself takes longer
than a microsecond, primarily due to a costly MMIO read (on many
controllers even three or more MMIO reads).
Unit tests with CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are added to
testlibraw as well.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
To conform with 'size' arguments of other libraw1394 calls, change the one in
raw1394_add_config_rom_descriptor() from quadlets to bytes. This breaks runtime
compatibility with potential clients that were written against B.J.'s original
patch, hence reorder arguments just to break compatibility also at compile time.
Change errno to ENOSYS (function not implemented) when called while running on
top of raw1394.
Allow &token to be NULL for convenience of clients which don't require
raw1394_remove_config_rom_descriptor().
Add exhaustive documentation. Much of it is copied from the documentation of
the underlying ioctl.
Add example code which doubles as unit test in testlibraw.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Since "testlibraw: test all cards instead of only the first", the
actual ROM content wasn't printed anymore due to a mistake in a
printf format string.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
The return value of any function should be checked if that function
uses the return value to provide some sort of status information.
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
While trying to track down some crashes in kino, I found the following problems
with libraw1394:
* There is a DIR* leak in raw1394_set_port().
* Lots of data structures are not fully initialized when calling IEEE1394
ioctl()s. These cause valgrind errors (benign, as valgrind does not know
how to interpret all ioctls. However these also cause kino to crash in
libraw1394. I've added a bunch of memset()s to prevent this problem from
happening.
Forward-ported to libraw1394 git tree by Jarod Wilson.
Added sendiso and dumpiso programs in tools directory.
Added man pages for sendiso and dumpiso in doc directory.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@66 53a565d1-3bb7-0310-b661-cf11e63c67ab
Stefan Richter
Erik Hovland
Philippe Troin
Dan Dennedy
Kristian Høgsberg
ddennedy
bencollins
aeb