Another RAIDframe question:
Suppose I have a level 5 RAIDframe set accross five components. I choose a
SPSU value of 8, i.e. 16kB as a stripe size.
Now, I write a suitably aligned 64kB chunk (i.e. four stripes worth) of data.
Will RAIDframe issue four 4kB writes to each component or a single 16kB
On Mon, Dec 10, 2012 at 12:58:49PM +0100, Edgar Fu? wrote:
Another RAIDframe question:
Suppose I have a level 5 RAIDframe set accross five components. I choose a
SPSU value of 8, i.e. 16kB as a stripe size.
Now, I write a suitably aligned 64kB chunk (i.e. four stripes worth) of data.
Will
On Mon, Dec 10, 2012 at 09:36:35AM -0600, David Young wrote:
What do people think about setting stricter guidelines for using the
C preprocessor than the guidelines from the past? Example guidelines:
The C preprocessor MAY be used for
1 Lazy evaluation: unlike a function call's arguments,
also, EINVAL doesn't seem like a great error code for this
condition. it's not an input parameter that's causing the
error, but rather that the required output format cannot express
the data to be returned. I think solaris uses EOVERFLOW for
this kind of situation, and ERANGE doesn't seem
On Mon, 10 Dec 2012, David Young wrote:
What do people think about setting stricter guidelines for using
the C preprocessor than the guidelines from the past?
Maybe.
The C preprocessor MUST NOT be used for
1 In-line code: 'static inline' subroutines are virtually always better
than macros.
On Mon, Dec 10, 2012 at 07:37:14PM +, David Laight wrote:
On Mon, Dec 10, 2012 at 09:36:35AM -0600, David Young wrote:
What do people think about setting stricter guidelines for using the
C preprocessor than the guidelines from the past? Example guidelines:
...
4 Computed constants.
On Mon, Dec 10, 2012 at 10:27:39PM +0200, Alan Barrett wrote:
On Mon, 10 Dec 2012, David Young wrote:
What do people think about setting stricter guidelines for using
the C preprocessor than the guidelines from the past?
Maybe.
The C preprocessor MUST NOT be used for
1 In-line code:
On Mon, Dec 10, 2012 at 07:37:14PM +, David Laight wrote:
On Mon, Dec 10, 2012 at 09:36:35AM -0600, David Young wrote:
What do people think about setting stricter guidelines for using the
C preprocessor than the guidelines from the past? Example guidelines:
...
4 Computed constants.
On Mon, Dec 10, 2012 at 02:28:28PM -0600, David Young wrote:
On Mon, Dec 10, 2012 at 07:37:14PM +, David Laight wrote:
a) #define macros tend to get optimised better.
Better even than an __attribute__((always_inline)) function?
I'd like to submit that neither are a good thing, because
In article 20121210195346.ga8...@apb-laptoy.apb.alt.za,
Alan Barrett a...@cequrux.com wrote:
also, EINVAL doesn't seem like a great error code for this
condition. it's not an input parameter that's causing the
error, but rather that the required output format cannot express
the data to be
On Mon, Dec 10, 2012 at 09:53:46PM +0200, Alan Barrett wrote:
also, EINVAL doesn't seem like a great error code for this
condition. it's not an input parameter that's causing the
error, but rather that the required output format cannot express
the data to be returned. I think solaris uses
On Mon, Dec 10, 2012 at 03:50:00PM -0500, Thor Lancelot Simon wrote:
On Mon, Dec 10, 2012 at 02:28:28PM -0600, David Young wrote:
On Mon, Dec 10, 2012 at 07:37:14PM +, David Laight wrote:
a) #define macros tend to get optimised better.
Better even than an
On Dec 10, 2012, at 4:18 PM, David Young wrote:
On Mon, Dec 10, 2012 at 03:50:00PM -0500, Thor Lancelot Simon wrote:
On Mon, Dec 10, 2012 at 02:28:28PM -0600, David Young wrote:
On Mon, Dec 10, 2012 at 07:37:14PM +, David Laight wrote:
a) #define macros tend to get optimised better.
On Mon, Dec 10, 2012 at 03:50:00PM -0500, Thor Lancelot Simon wrote:
On Mon, Dec 10, 2012 at 02:28:28PM -0600, David Young wrote:
On Mon, Dec 10, 2012 at 07:37:14PM +, David Laight wrote:
a) #define macros tend to get optimised better.
Better even than an
On Mon, Dec 10, 2012 at 09:26:08PM +, paul_kon...@dell.com wrote:
On Dec 10, 2012, at 4:18 PM, David Young wrote:
On Mon, Dec 10, 2012 at 03:50:00PM -0500, Thor Lancelot Simon wrote:
On Mon, Dec 10, 2012 at 02:28:28PM -0600, David Young wrote:
On Mon, Dec 10, 2012 at 07:37:14PM
On Dec 10, 2012, at 5:07 PM, David Laight wrote:
On Mon, Dec 10, 2012 at 09:26:08PM +, paul_kon...@dell.com wrote:
On Dec 10, 2012, at 4:18 PM, David Young wrote:
On Mon, Dec 10, 2012 at 03:50:00PM -0500, Thor Lancelot Simon wrote:
On Mon, Dec 10, 2012 at 02:28:28PM -0600, David
Explicit enums are a little better, no? And they do make things a
lot more obvious when debugging.
Sometimes. (Ab)using enums for bitmasks or other things that get
arithmetic applied to them (eg, O_EXEC, to pick a recently-discussed
example) is, IMO, broken - besides being unwarranted
I'd like to submit that neither are a good thing, because human
beings are demonstrably quite bad at deciding when things should be
inlined, particularly in terms of the cache effects of excessive
inline use.
Compilers are no better when - as is often the case for NetBSD - there
is no
Consider the following code:
#define cmd(n) \
if (__predict_true(ring_ptr ring_end)) \
*ring_ptr++ = n; \
else { \
ring_ptr = ring; \
*ring_ptr++ = n; \
ring_wrap_count++; \
}
for (;;) {
if
On Mon, Dec 10, 2012 at 09:23:15PM +, David Laight wrote:
Then people get upset because they say function foo() isn't allowed
to set errno to 'bar'.
It is rather a shame that posix tries to list all errno a function
can return, not just those for explicit 'likely' (ie normal)
On Mon, Dec 10, 2012 at 09:36:35AM -0600, David Young wrote:
What do people think about setting stricter guidelines for using the
C preprocessor than the guidelines from the past? Example guidelines:
The C preprocessor MAY be used for
1 Lazy evaluation: ...
2 Lexical manipulation: ...
Hi
I am trying to map PCI device memory using mmap() to user space for
powerpc based platform. I came across previous email thread where it
is mentioned that it is possible to mmap PCI memory using pcimmap()
implemented in dev/pci/pci_usrreq.c.
I wrote a small application to map the the PCI
I would like to propose an additional, perhaps controversial, use.
5 Breaking the flow of control:
#ifdef K5BAIL(x) do {
ret = x;
if (ret) {
/* format error message and whatnot
* in terms of #x.
Then people get upset because they say function foo() isn't allowed
to set errno to 'bar'.
Then how do you sanely write error handling routines? The error
returns form part of the interface and should be documented as such.
There are two kinds of error returns.
There are error returns which
On Tue, Dec 11, 2012 at 01:27:09AM +, Roland C. Dowdeswell wrote:
As an example, I often define a macro when I am using Kerberos or
GSSAPI that looks roughly like:
#ifdef K5BAIL(x) do {
ret = x;
if (ret) {
/* format error message
(Okay, that's not quite true. Using always_inline doesn't necessarily
mean committing to gcc. But _depending on_ always_inline does, ISTM.)
there are at least 3 other compilers i'm aware of that support
always_inline attribute, along with many of other GCC specific
features that aren't part
On Mon, Dec 10, 2012 at 06:47:16PM -0500, Mouse wrote:
b) __LINE__ (etc) have the value of the use, not the definition.
Yes, but if you use static inlines, the debugger's got both -- which
it won't, if you use macros...
Huh?
Okay, what's the static inline version of log() here?
27 matches
Mail list logo
