In other places, the exit status of make is carefully chosen to be 0
(success), 1 (did not make everything), 2 (other error). Using a signal
number is not guaranteed to be consistent among operating systems and is
therefore a weird choice.
since there are already tests for audio this is focused on making
sure the ioctls translate properly and implement the necessary OSS
compat quirks.
right now this only covers the dsp ioctls, it should also cover the
mixer ioctls, although that's significantly harder.
The epilogues are the same, so this is harmless, but if they ever
changed (e.g. after rearranging the register usage) it would be broken
in a very confusing way.
pic->pic_addroute should not enable interrupt, because callers expect
interrupts have been disabled until they call pic->pic_hwunmask.
By the way, the old implement writes zero to Vector Control for MSI-X Table
Entries, howerver it must be read and updated. Because, there are not only
Mask Bit but also ST lower and ST upper.
Documents say:
82598:
All of bit 31(OTHER bit) of EIxx are reserved. In reality, at least
EIMS_OTHER and EIMC_OTHER exist and the OTHER interrupt doesn't work
without EIMS_OTHER.
Other than 82598:
EIMS_OTHER is read only and EIMC_OTHER doesn't exist. If one of
bit 29..16 is set, EIMS_OTHER is set to 1 (Note that bit 30(TCP timer
isn't included)). Even if write bit 31 of EIMC to 1, it's ignored
(EIMS_OTHER doesn't set).
We introduced new spin mutex in ixgbe.c rev. 1.260, so it's OK to remove
EIMC_OTHER stuff. We already set EIMS_OTHER in if_init(), so keep it for
82598. No functional change other than 82598.
Another solution is to control bit 30..16 directly to mask/unmask interrupt
instead of the mutex.
TODO:
Some MSI-X interrupt(LSC, module insertion/removal etc.)'s mask/unmask
code between ixgbe_msix_admin() and ixgbe_handle_admin() may be wrong.
It'll be fixed later.
They are all templates with a single %s placeholder, so embed this
unambiguously in the variable name. The previous variable names didn't
provide any clue that echoCmd, execIgnore and errExit had a lot in
common.
Flags of similar names are also available in CmdOpts (global command
line options) and Job. The new name CommandFlags emphasizes that these
flags apply to the smallest scope possible, which is a single command,
as opposed to the whole GNode/Job.
They have never been related. Furthermore, Job.errOn is really tricky
to reach at all. To do that, one has to define a custom shell and set
hasErrCtl=true. The manual page has an example for that, but it's
probably not use in practice, just like the possibility to use the C
shell for all commands.
Having all these flags in a single bitmask makes it harder to see where
exactly they can possibly be used since their state could also be
modified using the unsuspicious job->flags = 0. Using individual names
just leaves the single memset, and that is only used during
initialization.
The "false" is supposed to be run not only if the command has the '-'
flag, but also if the target is marked as .IGNORE or if the command line
option -i is given.
After the failed command, the remaining commands are skipped, therefore
the final echo for the empty line had to be moved up, at the beginning
of the target.
The code in JobPrintSpecials is rather complicated and contains
surprising interaction between some of the switches.
To see the exact effects of the switches, record the current state and
its output, to prevent accidental breakage during the upcoming
refactorings.
rillig