I have a bash script which executes a multi-line command multiple times and I am changing the some values on each iteration. Here is my code below:
for (( peer=1; peer<=$nodesNum;peer++ ))
do
echo "Starting peer $peer"
nodeos -p eosio -d /eosio_data/node$peer --config-dir /eosio_data/node$peer --http-server-address=127.0.0.1:$http \
--p2p-listen-endpoint=127.0.0.1:$p2p --access-control-allow-origin=* \
-p "user$peer" --http-validate-host=false --signature-provider=EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEY:5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3 \
--max-transaction-time=1000 --genesis-json /eosio_data/genesis.json --wasm-runtime=wabt --max-clients=2000 -e \
--plugin eosio::chain_plugin --plugin eosio::producer_plugin --plugin eosio::producer_api_plugin \
--plugin eosio::chain_api_plugin \
--p2p-peer-address localhost:8888 \
&>eosio_data/logs/nodeos_stderr$p2p.log & \
sleep 1
http=$((http+1))
p2p=$((p2p+1))
done
I need to add a --p2p-peer-address localhost:$((9010 + $peer)) command multiple times for each peer as part of the multi-line command. I new to bash scripting and I couldn't find a similar example.
It's not entirely clear what you need, but I think it's something like the following. An array of --p2p-peer-address options is created, then incorporated
into the larger set of common options. Each call to nodeos then has some peer-specific options in addition to the common options.
# for example
HTTP_BASE=8080
P2P_BASE=12345
# Set of --p2p-peer-address options for shared by all calls.
for ((peer=1; peer <= $nodesNum; peer++)); do
peer_args+=(
--p2p-peer-address
localhost:$((9010+$peer))
)
done
# These are the same for all calls
fixed_args=(
-p eosio
"--access-control-allow-origin=*"
--http-validate-host=false
--signature-provider=EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEY:5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
--max-transaction-time=1000
--genesis-json /eosio_data/genesis.json
--wasm-runtime=wabt
--max-clients=2000
-e
--plugin eosio::chain_plugin
--plugin eosio::producer_plugin
--plugin eosio::producer_api_plugin
--plugin eosio::chain_api_plugin
--p2p-peer-address localhost:8888
"${peer_args[#]}"
)
for ((peer=1; peer<=$nodesNum; peer++)); do
# Call-specific arguments, followed by common arguments.
# $peer is either incorporated into each argument value
nodeos -d /eosio_data/node$peer \
--config-dir /eosio_data/node$peer \
--http-server-address=127.0.0.1:$((HTTP_BASE + $peer)) \
--p2p-listen-endpoint=127.0.0.1:$((P2P_BASE + $peer)) \
-p "user$peer" \
"${fixed_args[#]}" \
&> eosio_data/logs/nodeos_stderr$((P2P_BASE + $peer)).log &
sleep 1
done
To avoid having each instance of nodeos try to connect to itself, build peer_args anew on each iteration of the loop. Remove "${peer_args[#]}" from the definition of fixed_args, then adjust the main loop like so:
for ((peer=1; peer <= $nodesNum; peer++)); do
peer_args=()
for ((neighbor=1; neighbor <= $nodesNum; neighbor++)); do
(( neighbor == peer )) && continue
peer_args+=( --p2p-peer-address localhost:$((9010+peer)) )
done
nodeos -d /eosio_data/node$peer \
--config-dir /eosio_data/node$peer \
--http-server-address=127.0.0.1:$((HTTP_BASE + $peer)) \
--p2p-listen-endpoint=127.0.0.1:$((P2P_BASE + $peer)) \
-p "user$peer" \
"${fixed_args[#]}" \
"${peer_args[#]}" \
&> eosio_data/logs/nodeos_stderr$((P2P_BASE + $peer)).log &
sleep 1
done
I think you were very close. The expression you authored --p2p-peer-address localhost:$((9010 + $peer)) can be inserted into your nodeos call as follows:
for (( peer=1; peer<=$nodesNum;peer++ ))
do
echo "Starting peer $peer"
nodeos -p eosio -d /eosio_data/node$peer \
--config-dir /eosio_data/node$peer \
--http-server-address=127.0.0.1:$http \
--p2p-listen-endpoint=127.0.0.1:$p2p \
--access-control-allow-origin=* \
-p "user$peer" \
--http-validate-host=false \
--signature-provider=EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEY:5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3 \
--max-transaction-time=1000 --genesis-json /eosio_data/genesis.json --wasm-runtime=wabt --max-clients=2000 -e \
--plugin eosio::chain_plugin --plugin eosio::producer_plugin --plugin eosio::producer_api_plugin \
--plugin eosio::chain_api_plugin \
--p2p-peer-address localhost:$((9010 + $peer)) &>eosio_data/logs/nodeos_stderr$p2p.log &
sleep 1
http=$((http+1))
p2p=$((p2p+1))
done
Where can I find the code for wait_event_interruptible in Kernel tree.
What I can find is wait_event_interruptible is defined as __wait_event_interruptible in . But I am unable to find the code .
Please help me out.
Consider a process which has gone to sleep by wait_event_interruptible. Suppose if there is an interrupt now and the interrupt handler wakes(wake_up_event_interruptible) up the sleeping process. For the process to wake up successfully should the condition given in wait_event_interruptible be true ?
Thanks
It's in include/linux/wait.h:
#define wait_event_interruptible(wq, condition) \
({ \
int __ret = 0; \
if (!(condition)) \
__wait_event_interruptible(wq, condition, __ret); \
__ret; \
})
...
#define __wait_event_interruptible(wq, condition, ret) \
do { \
DEFINE_WAIT(__wait); \
\
for (;;) { \
prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE); \
if (condition) \
break; \
if (!signal_pending(current)) { \
schedule(); \
continue; \
} \
ret = -ERESTARTSYS; \
break; \
} \
finish_wait(&wq, &__wait); \
} while (0)
Answering your second question, yes.
Whenever an interrrupt handler (or any other thread for that matter) calls wake_up() on the waitqueue, all the threads waiting in the waitqueue are woken up and they check their conditions. Only those threads whose conditions are true continue, the rest go back to sleep.
See waitqueues in LDD3.
Use ctags or cscope so that you can easily find definitions like these.
Can you explain me this code ? I really don't understand it.
See http://lxr.free-electrons.com/source/arch/arm/include/asm/uaccess.h#L70
#define __addr_ok(addr) ({ \
unsigned long flag; \
__asm__("cmp %2, %0; movlo %0, #0" \
: "=&r" (flag) \
: "" (current_thread_info()->addr_limit), "r" (addr) \
: "cc"); \
(flag == 0); })
/* We use 33-bit arithmetic here... */
#define __range_ok(addr,size) ({ \
unsigned long flag, roksum; \
__chk_user_ptr(addr); \
__asm__("adds %1, %2, %3; sbcccs %1, %1, %0; movcc %0, #0" \
: "=&r" (flag), "=&r" (roksum) \
: "r" (addr), "Ir" (size), "" (current_thread_info()->addr_limit) \
: "cc"); \
flag; })
This is from ARM Linux kernel, __range_ok
As a general source of info regarding the register usage and other decorations, look at the docs for GCC Extended Inline Assembly
I suggest you run this source through
gcc .... -S
to see what the resultant assmebly generated is.
You could also run
objdump -dC -S <objectfile.o>
You will need objdump from your cross-compiler toolchain.
Also, compile with debug information to get source annotation (-S).
Compile with -O0 to avoid confusion due to optimization.
I want to fade a track in and out at specific time codes. For example, I would like to take an audio file, and:
Start it at 100% Volume
Fade it to 20% at 2 seconds
Fade it to 100% at 4 seconds
Fade it to 20% at 6 seconds
Fade it to 100% at 8 seconds
Fade it to 20% at 10 seconds
Fade it to 100% at 12 seconds
Fade it to 0 at 14 seconds
I've been testing this with a constant tone generated by ecasound so that I can open the resulting file in Audacity and see the results visually. As far as I can tell, increasing the amplitude is relative, while decreasing it is not. It seems that if I fade the amplitude up, it affects the relative volume of the whole track and not just at the specific time I set the fade, which is where I'm getting lost.
Example commands
# generate the tone
ecasound -i tone,sine,880,20 -o:tone.wav
# Just the test to see that i can fade start it at 100 and fade it to 20.
ecasound -a:1 -i tone.wav -ea:100 -kl2:1,100,20,2,1 -a:all -o:test_1.mp3
# Fade it out and in
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,100,20,2,1 \
-ea:100 -kl2:1,20,100,4,1 \
-a:all -o:test_2.mp3
# Fade it out and in with a peak of 500
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,100,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-a:all -o:test_3.mp3
# Fade it out from 500, out, and then back to 500
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-a:all -o:test_4.mp3
# Fade it out from 500, out to a low of 10, and then back to 500
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,10,2,1 \
-ea:100 -kl2:1,10,500,4,1 \
-a:all -o:test_5.mp3
# Fade it out from 1000, out to a low of 10, and then back to 1000
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,1000,10,2,1 \
-ea:100 -kl2:1,10,1000,4,1 \
-a:all -o:test_6.mp3
# The eventual result I'm looking for
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-ea:100 -kl2:1,500,20,6,1 \
-ea:100 -kl2:1,20,500,8,1 \
-ea:100 -kl2:1,500,20,10,1 \
-ea:100 -kl2:1,20,500,12,1 \
-ea:100 -kl2:1,500,0,14,4 \
-a:all -o:test_7.mp3
The Results
The best I can tell from these results is that the amplitude of the whole track is relative to the difference between the low and the peak of all the fading effects. I'm not sure if this result is expected, but it's very confusing.
Also, in the last result (second to last in the image), the fades are no longer taking a full second each. In order to figure out why that may be, I took the final fade-to-zero off and the durations were back to normal. This does not seem like expected behavior.
# "Fixing" the fade durations
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-ea:100 -kl2:1,500,20,6,1 \
-ea:100 -kl2:1,20,500,8,1 \
-ea:100 -kl2:1,500,20,10,1 \
-ea:100 -kl2:1,20,500,12,1 \
-a:all -o:test_8.mp3
As a side note, I've also tried changing the -ea values to the "current" amplitude with every line. It didn't make any difference (no matter what I set -ea to)
I have the very latest installed from git (2.8.1+dev). I had these same issues with 2.7.0, which is why I upgraded and eventually found myself here.
Am I doing this wrong?
-kl2
After a few hours of head scratching, I finally think I have it figured out. The "From" amplitude on every fade needs to be 100. If you are increasing the amplitude, the "To" amplitude is maximum / from * to.
So if you're trying to go from 20 to 100, it's 100 / 20 * 100 or 500. If you're trying to get to 120: 100 / 20 * 120 or 600. I assume this all makes perfect sense to someone, but I was perfectly stumped.
The working example (with a slightly higher bottom range in the middle to demonstrate):
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,100,20,2,1 \
-ea:100 -kl2:1,100,500,4,1 \
-ea:100 -kl2:1,100,40,6,1 \
-ea:100 -kl2:1,100,250,8,1 \
-ea:100 -kl2:1,100,20,10,1 \
-ea:100 -kl2:1,100,500,12,1 \
-ea:100 -kl2:1,100,0,14,1 \
-a:all -o:test_7.mp3
And the output:
Keep in mind that these amplitudes are still relative. If you're going from 45% to 90%: 100 / 45 * 90 = 200, and then now if you drop to 20% of the current amplitude, it's actually 18% (.20 * 90), so going back to 100 would be 100 / 18 * 100 = 555.56
-klg
Just as I figured this out, and came here to post, I received a response from the ecasound mailing list. It's not a direct answer to the kl2 issue, but offers an alternative, easier-on-the-brain answer, which is the klg parameter.
-klg:fx-param,low-value,high-value,point_count,pos1,value1,...,posN,valueN
Generic linear envelope. This controller source can be used to map
custom envelopes to chain operator parameters. Number of envelope
points is specified in 'point_count'. Each envelope point consists of
a position and a matching value. Number of pairs must match
'point_count' (i.e. 'N==point_count'). The 'posX' parameters are given
as seconds (from start of the stream). The envelope points are
specified as float values in range '[0,1]'. Before envelope values are
mapped to operator parameters, they are mapped to the target range of
'[low-value,high-value]'. E.g. a value of '0' will set operator
parameter to 'low-value' and a value of '1' will set it to
'high-value'. For the initial segment '[0,pos1]', the envelope will
output value of 'value1' (e.g. 'low-value').
Here's the command to do what I need using klg instead of kl2:
ecasound -a:1 -i:tone.wav -ea:100 \
-klg:1,0,100,14,2,1,3,0.20,4,0.20,5,1,6,1,7,0.40,8,0.40,9,1,10,1,11,0.20,12,0.20,13,1,14,1,15,0 \
-o:test.mp3
The output is exactly the same as the 2nd track on the image.
This resulting command line is definitely a bit harder to read and hence debug, but may actually be easier to generate dynamically. Regardless, I now have 2 working options to resolve this problem.
And finally, here are my notes for how I figured out the coordinates of the klg command. The asterisks are the "points" which are listed in the klg parameter, the numbers at the top are seconds:
0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1.0 --* *-* *-* *-*
~ \ / \._./ \ / \
0.2 *-* *-* \
0.0 *----------
I hope this helps someone save at least the amount of hair that i've lost scratching my head.
I know you can compare the length but many hash types have the same lengths.
Is there a way to identify a hash's type and whether it has been salted?
For example:
hash=2bf231b0e98be99a969bd6724f42a691
hash=4ac5a4ff764807d6ef464e27e4d1bee3
hash=4d177cec31d658ed22cc229e45d7265e
Yes, it is possible to a degree of some certainty to identify the type of hash algorithm that was used.
One tool that I use a lot to do this is hash-identifier.
For example, I create a hash of the Hash_ID.py file:
$ openssl sha -sha256 Hash_ID.py
SHA256(Hash_ID.py)= 5382a8826c972f8fa8687efe1f68e475c02af4bf542b0d7e68b9deffd388db96
When running Hash_ID.py it will ask for the Hash to be entered:
$ python Hash_ID.py
#########################################################################
# __ __ __ ______ _____ #
# /\ \/\ \ /\ \ /\__ _\ /\ _ `\ #
# \ \ \_\ \ __ ____ \ \ \___ \/_/\ \/ \ \ \/\ \ #
# \ \ _ \ /'__`\ / ,__\ \ \ _ `\ \ \ \ \ \ \ \ \ #
# \ \ \ \ \/\ \_\ \_/\__, `\ \ \ \ \ \ \_\ \__ \ \ \_\ \ #
# \ \_\ \_\ \___ \_\/\____/ \ \_\ \_\ /\_____\ \ \____/ #
# \/_/\/_/\/__/\/_/\/___/ \/_/\/_/ \/_____/ \/___/ v1.1 #
# By Zion3R #
# www.Blackploit.com #
# Root#Blackploit.com #
#########################################################################
-------------------------------------------------------------------------
HASH: 5382a8826c972f8fa8687efe1f68e475c02af4bf542b0d7e68b9deffd388db96
Possible Hashs:
[+] SHA-256
[+] Haval-256
Least Possible Hashs:
[+] GOST R 34.11-94
[+] RipeMD-256
[+] SNEFRU-256
[+] SHA-256(HMAC)
[+] Haval-256(HMAC)
[+] RipeMD-256(HMAC)
[+] SNEFRU-256(HMAC)
[+] SHA-256(md5($pass))
[+] SHA-256(sha1($pass))
The way Hash ID works is by checking the hash given against criteria for all the hash types it supports and will give a list of possible hash types.
That particular example is a 32 character alphanumeric representation, which is almost certainly MD5.
SHA-1 usually comes as a 40 character alphanumeric string (as does SHA-0)
MD5 and SHA-1 account for the vast majority of hashes you'll find in the wild.
No; you pretty much can only identify it by the length.
-- Edit:
Obviously, however, if you have access to the program generating the hashes, and you can provide input, then you can compare with some result you also calculate (assuming you know the salt.
If you're really stuck, you can also infer it from the language that's being used (i.e. if it's PHP, it's most likely MD5), and so on.
But from a technical point of view, there is no way to identify a hash; as it would be counter-productive to the goal of security :) (it would take up useless bits in the hash itself to do this identification).
Post from the future:
2bf231b0e98be99a969bd6724f42a691 MD5 : gombaliste0
4ac5a4ff764807d6ef464e27e4d1bee3 MD5 : gombaliste2
4d177cec31d658ed22cc229e45d7265e MD5 : gombaliste129