I found that on linux 3.0+ GFP_ZERO is no longer defined in headers.
All I found in gfp.h was,
/* Plain integer GFP bitmasks. Do not use this directly. */
...
#define ___GFP_ZERO 0x8000u
I've checked those "exported" bit masks, on one uses GFP_ZERO.
And the author says Do not use this directly, so, how should I get zeroed page,
Is kmalloc + memset the only option I have now?
I think the expected way to zero is kzalloc():
https://www.kernel.org/doc/htmldocs/kernel-api/API-kzalloc.html
but obviously alloc + memset works too.
Update
Sample diff from CFQ showing the expected updates:
- cfqd = kmalloc_node(sizeof(*cfqd), GFP_KERNEL | __GFP_ZERO, q->node);
+ cfqd = kzalloc_node(sizeof(*cfqd), GFP_KERNEL, q->node);
See also this: https://stackoverflow.com/a/12095263/2908724
Related
I see
(in Version 1.2.49, Linux Foundation ):
png_uint_32 png_get_iCCP(png_structp png_ptr, png_infop info_ptr, png_charpp name, int * compression_type, png_charpp profile, png_uint_32 * proflen);
And (in version 1.6.37):
png_uint_32 png_get_iCCP(png_const_structrp png_ptr, png_inforp info_ptr, png_charpp name, int *compression_type, png_bytepp profile, png_uint_32 *proflen);
The main difference is the incompatible change of the fifth parameter, from type char ** to type png_byte **.
Now, I definitely accept that the newer form is correct.
But that doesn't help if you want to be able to build with any version of the library.
My basic question is: When did this change take place?
One annoying part of this change is that it went unnoted in the API documentation, probably in part because said documentation doesn't even mention types.
I figure the compile-time test will look something like:
#if (PNG_LIBPNG_VER>=10402)
but that I would need to know what number to put in.
I figure my alternative is to write some autoconf tests.
As an additional question: Are there any other incompatible API changes in libpng's history?
I ran into a memory error so I'm trying to allocate more memory to the server, as instructed by the IDE. However, it doesn't recognise the class method which is clearly documented. What could have possibly gone wrong??
There is absolutely nothing to my code, it's literally just
ServerOptions.memSize = 65536;
I've also tried what I found on a blog, which is
Server.options.memSize = 65536;
Which also does not work. Please help!! I want to make music!
To refer to the current server, use the global variable 's'. Also, capitalization counts.
s.options.memSize = s.options.memSize * 2;
I am looking at some old MetaEditor4 / MQL4 code, where a local variable was declared twice:
......
1 int start()
2 {
3 if (1==2)
4 {
5 double myVar = 1;
6 } else
7 {
8 double myVar = 2;
9 }
10 return;
11 }
.......
The compilation process in MetaEditor, version 5.00, build 1601, fails with:
'myVar' - variable already defined in line 8.
If I remove the line 8, the compilation goes well.
My questions are:
1. Is there any option in MetaEditor that tolerates the multiple declaration of a local variable?
2. In previous versions of MetaTrader Terminal 4 / MetaEditor and .MQ4 code: was it possible to declare a local variable more than once in such a situation?
3. The MetaEditor has the version 5.00, build 1601, but the extension of the code is .mq4 and it was installed together with the MetaTrader Terminal software MetaTrader4 ( from FXCM ). Therefore I assume I can still use .MQ4 code with it. Is there any chance to get a pure MQL4 installation from somewhere?
Whenever I install mt4 ( from e.g.: mt4 download), it ends up
with the mt5 installer.
Prologue:
The worlds of MQL4 evolve. One may try to circumvent this fact, but finally, at one's own disappointment, attempts to avoid evolution will sooner or later go in vain.
Having been thrown into a need to re-engineer code-base spanning a few man*decades in size, I can tell you many stories about what worked and what did not.
An "Old code" v/s a New-MQL4.56789
If just one thing ought be taken from this, never try to "circumvent" New-MQL4, but rather review the code and refactor the "Old code" - this is a way safer way to survive ( way longer ).
Yes, there are chances ( zero warrants, just a few chances left temporarily on the table ) the new compiler version will remain able to generate an executable version of the code, but given a new set of rules have already come in the city, the game will not last long.
Ad 1 + 2 )Compiler still tolerates multiple declarations, but not in one scope
If new version of a compiler defined that any variable is declared only relative to it's scope of validity, the serious programmer ought take this as a general principle. The code above actually has other problem, right nailed to the scope-of-validity:
2 ...
3 if ( 1 == 2 ) {
4 ...
5 double myVar = 1; // myVar declared & known |since HERE >
6 ... // masking any other,|known HERE :
7 ... // |known HERE :
8 } else // |till HERE . Undef further
9 {
10 ...
11 double myVar = 2; // myVar declared & known |since HERE >
12 // masking any other,|known HERE :
13 ... // |known HERE :
14 } // |till HERE . Undef further
so, if there were any _global_ scope'd variable with the same name myVar, it will not be "visible" during an existence of locally declared variable, wearing the same name.
Finally, having the code-execution escaped from any of the lines 8 or 14 further, the locally there declared variable double myVar simply ceased to exist anymore and this behaviour is principally correct ( and the "older" compiler releases were tolerating a sort of dangerous habit of side-effects, during years of tolerating scope-of-validity spillover(s), so it was the high time to clean the rules, so as to meet a fair level of C/S standards.
Ad 3) language receives a lot from MQL5, even if not used in MQL4
Yes, MetaEditor will correctly compile a MQL4 code into .mq4 code-execution format, no problem here. Even an auto-update process started to go independently from MT4 Terminal platform (auto-)updates ( so you will quite often see new Help file coming and enforced re-compilation of all your localhost visible .MQ4 assets into updated .EX4 format, so "Do not panic."
Better never install a Broker-agnostic MT4, always go to your Broker's Support and get installation package & help from your Broker. This is business relation you have signed in a contract, so keep these strings as you are going to trade your money on a table they operate under the set Terms & Conditions. Some Brokers have means of platform customisations, so rather benefit from their custom settings that will match their Server-side automation.
It is more a question of economy of R&D efforts. ( May read a lot about language components injected from the MQL5 domain in the IDE Editor MQL4 Help ). This is a natural will of the product design strategy, not to double efforts on a dual-line. Without doubts, there are many details the Help file could be improved and better maintained, the common sense here is to live with the facts and re-learn what newly introduced features remain neutral for the MQL4 code base and what new things may actually help one a lot in aspects, where older compilers were short in powers.
If one objects that some compiler / platform re-design steps were bad, I would agree on a single-thread, platform-critical, potentially blocking, concentration of executing all the CustomIndicator-s in just one SPoF-thread.
But C'est La Vie, until system architects will not review this SPoF, the platform will remain susceptible to crashes from this feature, but the ball is on the other side of the court and a change will have to be implemented there.
the code might be run with 'strict' or non-strict mode.
strict means that variable must be declared within its scope, non-strict - all the mess that you have now.
so put #property strict at the beginning of the file
open a demo account somewhere and install mt4 there. demo can be valid for 30 days only with registration via web-site of a broker or with unlimited and demo opened from mt4 (example - Alpari)
I'm trying my driver with Driver Verifier turned on in Windows 7 x64, and get IRQL_NOT_LESS_OR_EQUAL(0A) bugcheck. From analyze -v info, it seems that the memory page of RtlAnsiCharToUnicodeChar function gets paged out, so calling that function causes bugcheck 0A . RtlAnsiCharToUnicodeChar is an ntoskrnl.exe exported function. Can it really be paged out? If so, how can I prevent it?
On spot debug info screen shot below:
yes. of course - very many ntoskrnl routines in PAGE* section.
RtlAnsiCharToUnicodeChar also paged - read in documentation:
IRQL <= APC_LEVEL
also read about DbgPrintEx routine
DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL. However, Unicode
format codes (%wc and %ws) can be used only at IRQL = PASSIVE_LEVEL.
and
However, the Unicode format codes (%C, %S, %lc, %ls, %wc, %ws, and
%wZ) can only be used with IRQL = PASSIVE_LEVEL.
so if you not use Unicode format you can use DbgPrint or KdPrint(this is macro) at any IRQL but if you use Unicode format - only on PASSIVE_LEVEL or APC_LEVEL (about APC_LEVEL i say by self)
You can try to use the MmLockPagableCodeSection on that specific routine to prevent it being paged out, however it's probably not advisable (and you don't know what dependencies it has, if they're located in pagable sections as well). In any case, make sure you read the documentation thoroughly.
A better approach is to run at Passive/APC level in the first place before invoking the printing function - e.g., by scheduling work item (you can also force lowering the IRQL with KeLowerIrql function but it's not advisable by MSFT).
On Solaris, processor_bind is used to set affinity for threads. You need to know the LWPID of the target thread or use the constant P_MYID to refer to yourself.
I have a function that looks like this:
void set_affinity(pthread_t thr, int cpu_number)
{
id_t lwpid = what_do_I_call_here(thr);
processor_bind(P_LWPID, lwpid, cpu_number, NULL);
}
In reality my function has a bunch of cross platform stuff in it that I've elided for clarity.
The key point is that I'd like to set the affinity of an arbitrary pthread_t so I can't use P_MYID.
How can I achieve this using processor_bind or an alternative interface?
Following up on this, and due to my confusion:
The lwpid is what is created by
pthread_create( &lwpid, NULL, some_func, NULL);
Thread data is available externally to a process that is not the one making the pthread_create() call - via the /proc interface
/proc/<pid>/lwp/<lwpid>/ lwpid == 1 is the main thread, 2 .. n are the lwpid in the above example.
But this tells you almost nothing about which thread you are dealing with, except that it is the lwpid in the example above.
/proc/pid/lwp/lwpid/lwpsinfo
can be read into a struct lwpsinfo which has some more information, from which you might be able to ascertain if you are looking at the thread you want. see /usr/include/sys/procfs.h
Or man -s 4 proc
The Solaris 11 kernel has critical threads optimization. You setup which threads require special care, the kernel does the rest. This appears to be what you want. Please read this short explanation to see if I understood what you want.
https://blogs.oracle.com/observatory/entry/critical_threads_optimization
The above is an alternate. It may not fly at all for you. But is the preferred mechanism, per Oracle.
For Solaris 10, use the pthread_t tid of the LWP with an idtype_t of P_LWPID in your call to processor_bind. This works in Solaris 8 -> 11. It works ONLY for LWP's in the process. It is not clear to me if that is your model.
HTH