[jira] [Updated] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-795:
--
Assignee: (was: James Peach)
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K,/* 3 */
> BUFFER_SIZE_INDEX_2K,/* 4 */
> BUFFER_SIZE_INDEX_4K,/* 5 */
> BUFFER_SIZE_INDEX_8K,/* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M,/* 13 */
> BUFFER_SIZE_INDEX_2M,/* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-795:
--
Fix Version/s: (was: 5.2.0)
sometime
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K,/* 3 */
> BUFFER_SIZE_INDEX_2K,/* 4 */
> BUFFER_SIZE_INDEX_4K,/* 5 */
> BUFFER_SIZE_INDEX_8K,/* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M,/* 13 */
> BUFFER_SIZE_INDEX_2M,/* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-795:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K,/* 3 */
> BUFFER_SIZE_INDEX_2K,/* 4 */
> BUFFER_SIZE_INDEX_4K,/* 5 */
> BUFFER_SIZE_INDEX_8K,/* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M,/* 13 */
> BUFFER_SIZE_INDEX_2M,/* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-795:
-
Description:
Right now, we have a set of defines, and APIs, which can take either a "index"
to a size (used e.g. for an allocator index), or a real size. Both of these are
currently int64_t in all APIs and member variables, and in the implementations,
the usage are sometimes overloaded (i.e. we do "size" calculations on top of
the indexes, making for real confusing code).
There's also a lack of proper identification of what is an "size index" type
(or parameter), and what is a "size". This makes for risky code.
I think we should clean up all the implementations and APIs, as follow
1) Make proper names of all APIs and macros, clearly indicating if it's working
on a size index or a size.
2) Keep only the size types, parameters and macros using int64_t. Do not
overload "real" size over the size indexes.
3) We either make the size indexes an "int" (or even a short), or perhaps even
better an enum (like below). All APIs, parameters, and member variables that
refer to such size indexes would use this appropriate type.
{code}
enum BufferSizeIndex {
BUFFER_SIZE_INDEX_128 = 0,
BUFFER_SIZE_INDEX_256, /* 1 */
BUFFER_SIZE_INDEX_512, /* 2 */
BUFFER_SIZE_INDEX_1K,/* 3 */
BUFFER_SIZE_INDEX_2K,/* 4 */
BUFFER_SIZE_INDEX_4K,/* 5 */
BUFFER_SIZE_INDEX_8K,/* 6 */
BUFFER_SIZE_INDEX_16K, /* 7 */
BUFFER_SIZE_INDEX_32K, /* 8 */
BUFFER_SIZE_INDEX_64K, /* 9 */
BUFFER_SIZE_INDEX_128K, /* 10 */
BUFFER_SIZE_INDEX_256K, /* 11 */
BUFFER_SIZE_INDEX_512K, /* 12 */
BUFFER_SIZE_INDEX_1M,/* 13 */
BUFFER_SIZE_INDEX_2M,/* 14 */
/* These have special semantics */
BUFFER_SIZE_NOT_ALLOCATED,
};
{code}
was:
Right now, we have a set of defines, and APIs, which can take either a "index"
to a size (used e.g. for an allocator index), or a real size. Both of these are
currently int64_t in all APIs and member variables, and in the implementations,
the usage are sometimes overloaded (i.e. we do "size" calculations on top of
the indexes, making for real confusing code).
There's also a lack of proper identification of what is an "size index" type
(or parameter), and what is a "size". This makes for risky code.
I think we should clean up all the implementations and APIs, as follow
1) Make proper names of all APIs and macros, clearly indicating if it's working
on a size index or a size.
2) Keep only the size types, parameters and macros using int64_t. Do not
overload "real" size over the size indexes.
3) We either make the size indexes an "int" (or even a short), or perhaps even
better an enum (like below). All APIs, parameters, and member variables that
refer to such size indexes would use this appropriate type.
{code}
enum BufferSizeIndex {
BUFFER_SIZE_INDEX_128 = 0,
BUFFER_SIZE_INDEX_256, /* 1 */
BUFFER_SIZE_INDEX_512, /* 2 */
BUFFER_SIZE_INDEX_1K,/* 3 */
BUFFER_SIZE_INDEX_2K,/* 4 */
BUFFER_SIZE_INDEX_4K,/* 5 */
BUFFER_SIZE_INDEX_8K,/* 6 */
BUFFER_SIZE_INDEX_16K, /* 7 */
BUFFER_SIZE_INDEX_32K, /* 8 */
BUFFER_SIZE_INDEX_64K, /* 9 */
BUFFER_SIZE_INDEX_128K, /* 10 */
BUFFER_SIZE_INDEX_256K, /* 11 */
BUFFER_SIZE_INDEX_512K, /* 12 */
BUFFER_SIZE_INDEX_1M,/* 13 */
BUFFER_SIZE_INDEX_2M,/* 14 */
/* These have special semantics */
BUFFER_SIZE_NOT_ALLOCATED,
};
{CODE}
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.1
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better
