This is my work but not home work. I am trying to come up decide how best to represent a data I have using a native data structure(By native i mean I cannot use STL in C++, its a C++ code. Its our design decision not to use STL and have no way to change it or violate it)
Data is as follows:
There is a variable say int to denote ipaddr say e.g. 192.168.10.77(lets say this is stored in a int which is uniquely obtained from the 192.168.10.77 ) which lets call deviceId.
Now for each such deviceId there are other fields multiple services associated to it say service 1, service2, etc... Number of services associated with each device is variable from one deviceId to another.
So a sample of data could look like:
192.168.10.77
service1
service2
service3
service4
192.168.10.98
service1
service2
192.168.10.97
service1
Right now I store it in a inefficient data structure as below.
I have a struct as:
typedef struct
{
deviceId d;
serviceId s;
}mystr;
And then I use an array of a struct which holds
mystr mylist[64];
so entries of this array look like
mylist[0].d = 192.168.10.77
mylist[0].s = service1
mylist[1].d = 192.168.10.77
mylist[1].s = service2
mylist[2].d = 192.168.10.77
mylist[2].s = service3
mylist[3].d = 192.168.10.77
mylist[3].s = service4
mylist[4].d = 192.168.10.98
mylist[4].s = service1
mylist[5].d = 192.168.10.98
mylist[5].s = service2
... ... and so on ....
Essentially the deviceId value is duplicated as many times as there are services associated to it.
I need some thing more efficient because later I have to group all the services associated with a device.
So to do that I might have to search for deviceId and club the services for it together. I don't know how I am going to search by deviceId as it can have any value.
What is a better way to represent this data using some optimal data structure ?
[ I can see it as linked list but could not come up with the struct Node{ } for it ]
typedef struct
{
deviceId d;
serviceId s[100]; more than 1 service for 1 device is required
`}mystr;
mystr mylist[64];`
or you can have a linked list like
` struct device
{
device id;
*service;
}
typedef struct serviceid{
{
*service;
}service;
`
point to null by last service id
Consider using gethostbyname and gethostbyaddr. First try one, if it fails, try the other. Then you only have to store one string.
How about this library to store it as a basic hash table?
http://troydhanson.github.com/uthash/
Disclaimer: I'm only vaguely familiar with C
You can have link list of devices with link list of services
typedef Service{
serviceId s;//store service id
Service *nextService;//link to the different services supported by the device, end by null
}*deviceServiceList;
typedef struct Device{
deviceId d;//store the device id
Service *s;//store the list of service available for this device
}myDevices;
the devices can be stored in a array of devices or u can create a link list of devices
Related
I work with cpu management in big.LITTLE boards and the board on which I am developing on has some ina231 power sensors. Which I believe are handled by the ina2xx_driver (this would make sense to me). My knowledge of drivers is still in development so I am unsure about how I should get the information I need to my CPU module out of the driver/devices, in a way that wont make the Linux gods angry.
The board has 4 sensors which I believe are then stored in the struct i2c_driver in the linked list struct list_head clients. If I have understood this correctly, then my initial idea was to export a pointer to the driver
static struct i2c_driver ina2xx_driver = {
.driver = {
.name = "ina2xx",
},
.probe = ina2xx_probe,
.remove = ina2xx_remove,
.id_table = ina2xx_id,
};
+struct i2c_driver *ina2xx_driver_p = &ina2xx_driver;
+EXPORT_SYMBOL(ina2xx_driver_p);
to my module which could then step through the linked list of i2c clients allowing me to access individual device information by doing something like this
struct i2c_client *tmp
struct list_head *pos;
struct list_head *clients_head = &ina2xx_driver_p->clients;
list_for_each(pos, clients_head){
tmp = list_entry(pos, struct i2c_client, detected)
struct ina2xx_data *data = ina2xx_update_device(tmp.dev);
ina2xx_get_value(data, $(attribute));
}
I haven't actually tried this, it's just how I imagine one solution being after reading the header files. Given my lack of knowledge on the recommended practice I thought it would be best to ask before wasting a day or two trying to implement something that is destined to fail.
Is there a more standardized way that is used in the kernel to get device driver or device pointers to access information or way to get device information without reading it from files?
I hope my question makes sense and thanks.
The ina231 sensor on your board is most likely instantiated from DeviceTree. If that is the case, and your driver is also instantiated from DT, then it would be natural to store a phandle to ina231 sensor as a property in your DT node. Then you can use of_find_node_by_phandle() to get a struct device_node and then use of_find_i2c_device_by_node to turn it into struct i2c_client.
An alternative approach would be to use bus_find_device() with &i2c_bus_type as a first argument and using your custom match function. See the of_find_i2c_device_by_node implementation as an example on how this could be used.
Note that none of that will be pretty since you are planning on using driver private internal data which itself isn't a nice practice.
I'm absolutely loving BreezeJS and was so surprised to see that my Enum values were being displayed as their text values and not their ordinal ones! What I would love to be able to do is, on the client side, open the MetadataStore, fetch the enumeration and modify it's textual properties for display purposes.
Is this currently possible? From my research it would appear not, but I'm wondering if there is perhaps a simple workaround. Everything I've tried has involved a large number of hacks and server-side attributes, but to no avail, or the solution just seemed overly complex and not worth the benefits.
Here is what I said about how to get the enum values from raw metadata in another SO comment.
The enum values are available in the metadata generated by EF and sent to a Breeze client. I agree Breeze should pick them up automatically and put them somewhere so you don't have to make a separate request for them or extract them from the raw metadata passed to the MetadataStore.fetchMetadata success callback. It's on our backlog.
Meanwhile, you'll have to get them by hand. There is a DocCode test that shows how:
/*********************************************************
* Can can get enum types from raw EF-generated metadata
* Related to feature request #2271: Extract enum values from server metadata
*************************************************************/
asyncTest("can get enum type from raw EF-generated metadata", function() {
var serviceName = testFns.foosMetadataServiceName;
var store = new breeze.MetadataStore();
store.fetchMetadata(serviceName)
.then(metaSuccess, metaFail).fail(handleFail).fin(start);
function metaSuccess(rawMetadata) {
ok(true, "foos metadata fetched");
var enumType = rawMetadata.schema && rawMetadata.schema.enumType;
if (enumType && enumType.name ==='Color') {
var members = enumType.member;
ok(members.length,
"should have several members; members are: " + JSON.stringify(members));
} else {
ok(false, "metadata should have had one enumType, 'Color'.");
}
}
function metaFail(error) {
ok(false, "foos metadata fetch failed: " + error.message);
}
});
we're using Breeze with NHibernate and wand to do the same. Metadata generated for NHibernate are standard breeze Metadata and doesn't contain the Schema part. Any ideas how to do it?
edit: To fix our issue I added a list of all used enums in the metadata(like the structuralTypes node). Then we cache it on the client when the metadata are retrieved.
https://github.com/lnu/breeze.server.net/commit/65ad687ad13c4dd9f4a6ab6a3ed09e407e2b58ec
Thanks
We are looking at syncing some of our LDAP (Active Directory) data with what is stored in SAP. SAP provides several function modules that allow you to write a custom program to handle mapping the data, but we are looking to use the provided solution that makes use of RSLDAPSYNC_USER.
The issue I'm having is understanding how the mapping of fields is performed in LDAPMAP. In particular, when performing the Mapping Overview, where are the structures as shown below defined?
Also, we have a function module that is currently available for grabbing all of the fields we would like to send to LDAP, but can the screen shown below be used to call a custom function module to grab the data I require? If so, then please give an example.
Thanks,
Mike
I am not sure if that is what you ask. As an answer to your second question:
You can give attributes that you want to get. The LDAP_READ function will return the results in entries parameter.
CALL FUNCTION 'LDAP_READ'
EXPORTING
base = base
* scope = 2
filter = filter
* attributes = attributes_ldap
timeout = s_timeout
attributes = t_attributes_ldap
IMPORTING
entries = t_entries_ldap "<< entries will come
EXCEPTIONS
no_authoriz = 1
conn_outdate = 2
ldap_failure = 3
not_alive = 4
other_error = 5
OTHERS = 6.
Entries parameter looks like:
Attributes parameter looks like:
Is there any benefit in having never-defined structures in C ?
Example in SQLite source code :
/* struct sqlite3_stmt is never defined */
typedef struct sqlite3_stmt sqlite3_stmt;
And the object is manipulated like so :
typedef struct Vdbe Vdbe;
struct Vdbe {
/* lots of members */
};
int sqlite3_step(sqlite3_stmt *pStmt) {
Vdbe *v = (Vdbe*) pStmt;
/* do stuff with v... */
}
So why not just use a usual abstract type, with the actual structure privately defined in foo.c source and a public typedef in foo.h header ?
It is defined like this to hide the implementation detail of sqlite3_stmt from the user, thus avoiding the internal states from being messed around. See Opaque pointer.
(This also forces the user only to use the type as a pointer since the structure sqlite3_stmt itself has incomplete implementation.)
Edit: VDBE (virtual database engine) is just "a" back-end of the SQLite3 API. I believe the back-end is changeable, thus a sqlite3_stmt* is not necessarily a Vdbe*. Not exposing Vdbe* in the API because the back-end detail should not be exposed.
To clarify: What you're asking is why SQLite does the above instead of doing this:
Header file:
typedef struct sqlite3_stmt sqlite3_stmt;
C file:
struct sqlite3_stmt {
/* lots of members */
};
int sqlite3_step(sqlite3_stmt *pStmt) {
/* do stuff with pStmt... */
}
(This is the canonical form of the "opaque pointer" pattern linked to in KennyTM's answer.)
The only good reason I can think of why SQLite does what it does is the following:
The backend code, I'm speculating, came before the API and used the name Vdbe -- the name probably means something related to the implementation along the lines of "virtual database entry" (guessing wildly here).
When time came to create the API, someone realized that the parameter required by sqlite3_step was a Vdbe but that this was not exactly a name that would convey a lot to the user of the API. Hence, from the user's point of view, a Vdbe is referred to as an sqlite3_stmt.
The point here, then, is to differentiate between two views of the same item: The backend thinks in terms of Vdbes (whatever they are) because that's a name that makes sense in the context of the implementation. The API talks about sqlite3_stmts because that's a name that makes sense in the context of the interface.
Edit: As Amarghosh points out, why not just do this to achieve the same effect?
typedef struct Vdbe sqlite3_stmt;
KennyTM points out a good possible reason (please vote him up, I don't want to siphon off his rep here): VDBE is only one of several possible backends; the interface uses a "generic" sqlite3_stmt, and this is then cast to whatever the backend uses to implement it.
I'm a bit confused about how to implement my state machine.
I already know it's hierarchical since some states share the same action.
I determine what I need to do by these parameters:
Class (Values are: Base, Derived, Specific)
OpCode
Parameter 1 - optional
Parameter 2 - optional
My hierarchy is determined by the Class and the OpCode represents the action.
Derived can use the OpCodes of Base and Specific can use OpCodes of both Base and Derived.
The naive implementation is the following:
void (*const state_table [MAX_CLASSES][MAX_OPCODES]) (state *) {
{base_state1, base_state2, NULL, NULL},
{base_state1, base_state2, derived_state1, NULL},
{base_state1,base_state2, derived_state1, specific_state3},
};
void dispatch(state *s)
{
if (state_table[s->Class][s->OpCode] != NULL)
state_table[s->Class][s->OpCode](s);
}
This will turn unmaintainable really quick.
Is there another way to map the state to a superclass?
EDIT:
Further calcualtion leads me to think that I'll probably use most if not all OpCodes but I will not use all of the Classes available to me.
Another clarification:
Some OpCodes might be shared through multiple derived and base Classes.
For example:
I have a Class called Any
which is a Base class. It has the
OpCodes: STATE_ON, STATE_OFF, STATE_SET.
I have another Class called
MyGroup which is a Derived class. It has the OpCodes:
STATE_FLIP, STATE_FLOP.
The third Class is a Specific
class called ThingInMyGroup which
has the OpCode:
STATE_FLIP_FLOP_AND_FLOOP.
So a message with class Any is sent from the server, recieved in all clients and processed.
A message with class MyGroup is sent from the server, recieved in all clients and processed only on clients that belong to MyGroup, any OpCodes that are valid for the Any class are valid for the MyGroup class.
A message with class ThingInMyGroup is sent from the server, recieved in all clients and processed only on clients that belong to MyGroup and are a ThingInMyGroup*, any **OpCodes that are valid for the Any class and MyGroup class are valid for the ThingInMyGroup class.
After a message is received the client will ACK/NACK accordingly.
I prefer not to use switch cases or const arrays as they will become unmaintainable when they get bigger.
I need a flexible design that allows me:
To specify which OpCodes are available
for each Class.
To specify a superclass for each Class and through that specification to allow me to call the function pointer that is represented by the current OpCode.
There are several ways to deal with this. Here is one:
edit -- with general purpose hierarchy added
typedef unsigned op_code_type;
typedef void (*dispatch_type)(op_code_type);
typedef struct hierarchy_stack hierarchy_stack;
struct hierarchy_stack {
dispatch_type func;
hierarchy_stack *tail;
};
void dispatch(state *s, hierarchy_stack *stk) {
if (!stk) {
printf("this shouldn't have happened");
} else {
stk->func(s, stk->tail);
}
}
void Base(state *s, hierarchy_stack *stk ) {
switch (s->OpCode) {
case bstate1:
base_state1(s);
break;
case bstate2:
base_state(2);
break;
default:
dispatch(s, stk);
}
}
void Derived(state *s, hierarchy_stack *stk ) {
switch(s->opcode) {
case dstate1:
deriveds_state1(s);
break;
default:
dispatch(s, stk);
}
}
...
NOTE : All function calls are tail calls.
This localizes your "class"es a good bit so that if you decide that Derived needs 100 more methods/opcodes then you only have to edit methods and the enum (or whatever) that you use to define opcodes.
Another, more dynamic way, to deal with this would be to have a parent pointer within each "class" that pointed to the "class" that would handle anything that it could not handle.
The 2D table approach is fast and flexible (Derived could have a different handler than Base for opcode 0), but it grows fast.
I wrote a little tool that generates code similar to your naive implementation based on a mini-language. The language just specified the state-opcode-action relationships, all of the actions were just C functions conforming to a typedef.
It didn't handle the HSM aspect, but this would be relatively easy to add to a language.
I'd recommend taking this approach -- create a little language that gives you a clean way to describe the state machine, and then generate code based on that machine description. That way when you need to insert a new state a month from now, the whole thing isn't a tangled mess to edit.
Let me know if you want the code and I'll make sure it's still available somewhere.