- There's no need for double error codes here, just break the
loop on first error we encounter.
- Now that fdio/ufdio error reporting is sane we dont need any
specially broken tests to avoid errors from fdno being -1
- Move the error tracking variables to the stack, doesn't make
much difference now but would allow for true per-iotype specific
error systems if we had such a thing, and tracking errors
in the stack they occurred.
- Change fdio error methods to pass stacks around.
- Return syserrno for fdError() - it might be useless for now but
that's still less broken than reporting errors on fdno -1, which
can never be the case on non-compressed fd, and on compressed ones
its always the case... Currently only compressed streams use
syserrno but no reason we couldn't use it for plain fd too.
- Return empty string instead of NULL from compressed stream errors
when there is no error.
Here is my updated patch adding AArch64 support. The main change was to
use CANONCOLOR=3 rather than 2.
--Mark
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- The lower level io-type specific methods mostly really just
want their own stack to get to their private data, rather than
the fd (which is available through the stack now as well)
- Change fdio read and write methods to pass stacks around with
minimal changes overall. They all need to be changed but doing
this in smaller pieces to avoid a humongous commit... Further
cleanups + sanity to follow once its all been done.
- Having fd NULL-checked for each these calls makes no sense, and
we'll shortly have more data in there + more uses for fdGetFps()
- Doesn't change anything, just preliminaries for next steps.
- Oops, the xz/lzma case was even more .. err .. creative than I
recalled. Revert this change for now, this needs a different kind of
approach to sanely fix.
- This reverts commit af61b0d925.
- Despite all the io types dutifully supplying such a method, the
fdio->_fopen() path is not (and has never been) used at all: the
compressed streams get opened on top of a file descriptor opened
by ourselves. So, lotsa code deleted, but no functional changes
as this code has never been wired up anywhere.
- There wouldn't be any particular advantage to using the path-based
opening over the fd-based one anyway, and while we *could* use that
as well, it would require jumping through extra hoops to support the
current "ufdio open always" semantics, so we might just as well
axe the lot. Bye bye.
- Explicit fdio and unspecified type use plain fdio, everything else
goes through ufdio for the open. Once we have the physical file
opened, open the compressed stream on top if necessary. This doesn't
actually *change* anything in here, just eliminates a whole lot
of unnecessary cruft.
- Now that we can, take advantage of iotFileno() for these too,
eliminating yet another subtly-different-from-everything-else
case. Of course the per-filetype fooFileno() vectors start
seeming fishy and at least redundant now but...
- Add a function to find io type by its type- or "friendly" name
and use that for finding the requested type in Fdopen(), which
apart from legacy gzdio assumptions now doesn't need to know
anything about our supported types.
- Eliminate yet another place where we manually test for each and every
known io type for no good reason at all. As it happens we only
need two simple handlers for these: one for non-compressed and
another one for compressed types.
- Eliminate another place where we manually test for each and every
known io type for no good reason at all. As it happens we only
need two simple handlers for these: one for non-compressed and
another one for compressed types.
- Plain fd types dont have a special _fopen() method so we can use
that to determine the kind of message we want to spit out, eliminating
the hysterical testing for each and every io type separately.
- These are not used at all, perhaps because they make no sense
to begin with... refcounting, underlying physical fd number
and FD_t allocation aren't going to be io type specific.
- Hardlinks have shared metadata by their very definition, it makes
no sense to keep resetting the metadata for all links we create.
Only set metadata for first non-skipped hardlink in a set.
- Return early for the highly special case of /dev/log
- Separate metadata (permissions, time stamps...) setting from
the renaming part: rename is always required, but setting
metadata is not (although we currently always do)
- No functional changes
Two hooks are currently added:
FSM_FILE_OPEN
called after fsmInit() has been called for the file during installation or erase.
FSM_FILE_CLOSE
called after fsmCommit() for the file during installation or after file has been removed on uninstallation
In addition FSM_FILE_CLOSE is called for each directory that isn't included in the package and was created by rpm
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Perhaps this had some kind of meaning for the ancient implementors,
but that meaning has gotten long since lost in the sands of time
and most likely no longer exists at all...
- While adding the outer locks before converting all of internals
is easier here, it makes it also easier to forget places since
its not actually forced :-/ oh well...
- Should've been in commit 2870caa14c
- Similar to the context object in rpmlog, hide the global context
behind a function call to force controlled context acquisition.
We're going in the opposite direction here (because its simpler in
this case): there's nothing but the lock in the context now.
- Acquire and release the context on entry to public API
entry- and exit points, this should be enough to guarantee basic
safety (as in "does not crash and burn") wrt threads. Assuming
there are no hidden writers behind the getter APIs...
- For thread *sanity* all the umphteen globals need to go into the
context which could be per-thread initialized but that's a longer
story...
- Turns out "destroying the object and release any resources used by the
lock" does not include *unlocking* the lock. How silly of me to think
it would...
- The static _printed tracking meant that the debug spew would only
be printed out for one package per process lifetime, regardless of
how many relocated packages there might be. rpmRelocateFileList()
will gets called twice for every relocated package within a
transaction, but then this is debug-only output to begin with.
When debugging we can live with a little extra spew...
- This is not a buffer where anything gets written to, its only
used as a source for writing zero-padding into signature headers.
Rename to "zeros" and make it const which it is.
- This makes "now" be "now" on "package query started" than
"some arbitrary point in process lifetime when", which could
in theory be arbitrarily long in the past. Which should be
a sane thing... and also avoids having to do pthread tricks
for such a silly and cheap-to-call thing.
- Keys are basically immutable and generally owned by the keyring
which doesn't currently doesn't expose anything about the keys
it owns... so there isn't perhaps that much need for locking,
except for keeping reference counts sane. Under that assumption
the keys are not locked from within keyring lookup and signature
verification, as it'd seem the keyring locking is sufficient
to keep our keys around during them. Just as well there might
be holes in this theory but gotta start someplace...
- While we're mostly interested in very limited thread-safety
where objects need to be kept private to the owning thread, being
able to share the keyring (from transaction set) seems desireable,
so lets try at least...
- Try to keep things as simple as possible: grab locks at the outer
level functions, dont bother optimizing for write-lock avoidance
in corner cases etc.
Panu Matilainen