libwebsockets user pointer in client callback - c

I'm developing a client using the venereable libwebsockets library.
I don't know where to assign a char * (somewhere during setup I presume) I have so that I can get my hands on the same via the void *user parameter in my client's lws_callback_function().
I've tried setting user in my lws_protocols, I've tried setting userdata in my struct lws_client_connect_info, and a bunch of other places I can't remember.

I got this to work, but took a bit of investigation..
stash user data in lws_context_creation_info:
struct app_data_t { int something; };
app_data_t app_data;
app_data.something = 123456;
...
lws_context_creation_info lws_cx_config;
...
lws_cx_config.user = &app_data;
...
lws_context * lws_cx = lws_create_context(&lws_cx_config);
recover user data from callback like this:
int callback(struct lws * wsi,
lws_callback_reasons reason,
void * pss_user_data, void * in, size_t len)
{
lws_context * lws_cx = lws_get_context(wsi);
app_data_t * app_data = (app_data_t *)(lws_context_user(lws_cx));
lwsl_user("callback: enter: something=%d", app_data->something);
...
}

I guess what you want is: a private data for every connection ?
A. If you just need to allocate a piece of memory, you can try this:
struct lws_protocols::per_session_data_size = 1024 bytes;
struct lws_context_creation_info::protocols = protocols;
and then you will get it in lws_callback(* user), user is a private 1024 bytes memory block.
B. If you need to pass a parameter and use it :
lws_client_conn_info.opaque_user_data = &mydata;
in lws_callback(*wsi) :
MyData *my_private_data = (MyData*)lws_get_opaque_user_data(wsi);

Related

How can a callback function be executed within a driver on linux?

I have to modify a driver that runs on linux to add a callback function that is invoked from an external application. I already have the code implemented but when it is executed when the computer starts up, the system gives an error and is blocked.
This is my new code on the driver side:
typedef void (*callbackFunctionNoParams) ();
typedef struct T_EXI_CONFIGURE_BUS_
{
T_mode mode;
unsigned short NumeroRT;
T_SA_Enable SA_Enable;
unsigned short MINOR_CYCLE;
callbackFunctionNoParams callback;
} T_EXI_CONFIGURE_BUS;
typedef struct PciExiDev_
{
/**
* It represents a char device to read/write
*/
struct cdev charDevice;
/**
* IRQ assigned
*/
unsigned int irq;
/**
* Callback function to be invoked
*/
callbackFunctionNoParams callback;
/**
* Device control block
*/
EXI_DCB theDCB;
} PciExiDev;
Execution code on driver side:
static long exi_ioctl( struct file * filep, unsigned int cmd, unsigned long arg )
{
PciExiDev * aPciExiDev = (PciExiDev *) filep->private_data;
int result = SUCCESS;
int i, j;
long ret = 0;
//printk("Ioctl received %d.\n",cmd);
switch( cmd )
{
case FIO_EXI_CONFIGURE_BUS:
{
T_EXI_CONFIGURE_BUS config;
T_LISTA_TRANS *auxTrans1, *auxTrans2;
T_TRANSACTION_DCB *transDCB1;
T_OPI opi;
T_EXIS exis;
unsigned short dato;
unsigned short datolong[2];
unsigned short ControlBlock[12];
// printk("Exi configure bus initiated.\n");
printk("TNB. Exi ioctl CONFIGURE BUS.\n");
copy_from_user( &config, (T_EXI_CONFIGURE_BUS *) arg, sizeof(T_EXI_CONFIGURE_BUS) );
LeerDatos( &aPciExiDev->theDCB, OPI_ADDRESS, 1, (unsigned short *) &opi, 1 );
aPciExiDev->callback = config.callback;
aPciExiDev->theDCB.modo = config.mode;
aPciExiDev->theDCB.CicloMenor = config.MINOR_CYCLE;
(*aPciExiDev->callback)();
...
New code on client side:
if( theHWConfiguration.existExi() )
{
T_EXI_CONFIGURE_BUS bus_config;
// Configura la tarjega exi en modo Bus Controller.
bus_config.mode = BC;
bus_config.NumeroRT = 28;
bus_config.MINOR_CYCLE = 20;
bus_config.callback = &bcInterruptHandler2;
status = ioctl( A_fd_exi, FIO_EXI_CONFIGURE_BUS, reinterpret_cast<long>( &bus_config ) );
}
return status;
}
void C_EXI::bcInterruptHandler2()
{
std::cout<< "bcInterruptHandler2" << endl;
}
And this is the execution code result:
Crash Image
If someone could help me or propose an alternative way of doing this I would be very grateful.
Your callback is bound to run at kernel space and then you write it to std::cout. While going through your code, it tells that there is a conflict between kernel mode address space and userside process address space. This means that if the callback function is declared in the userside but instead called in the kernel space, there would be an error.
The crash image suggests that somewhere in your code you have an invalid pointer that you are trying to access. I am afraid I cannot debug your code with the little context provided, but I can give you some suggestions:
Try to avoid casting until is strictly necessary.
When you are casting to a pointer, double-check that this is exactly what you need to do.
In the error message there is also the call stack: take a look at it in order to identify where is the error.
You can simply add some printk("%p", pointer) in your code to debug the content of your variables.

Tcl pathInFilesystemProc get current filesystem

When creating a vfs using the tcl api how do you get the current filesystem in Tcl_Filesystem.pathInFilesystemProc
My code looks something like this:
typedef struct {
FILE* dbFile;
/*...*/
} FSBackend;
void createFS(const char* dbFile)
{
FSBackend* fsback = (FSBackend*)malloc(sizeof(FSBackend));
initDb(fsback,dbFile);
Tcl_Filesystem tfs;
tfs.typeName="Db Fs";
tfs.structureLength = sizeof(Tcl_Filesystem);
tfs.version = TCL_FILESYSTEM_VERSION_1;
tfs.pathInFilesystemProc = inFsProc;
/*...*/
Tcl_FSRegister((void*),tfs);
}
int inFsProc(Tcl_Obj* pathPtr,ClientData* cd)
{
/* How do I get my FSBackend struct here */
FSBackend* bk = /* ? */
int len;
const char* searchPath = Tcl_GetStringFromObj(pathPtr,&len);
char* foundPath = findFileInDb(searchPath,bk);
if (foundPath == 0) {
return -1;
}
cd = buildInternalRep(foundPath,bk);
return TCL_OK;
}
/**
...
*/
int main()
{
createFS("db1.db");
createFS("db2.db");
}
How do I, in inFsProc get back the struct I passed into Tcl_FSRegister?
The Tcl_FSData function says it can get it but I would then need to get a Tcl_Filesystem pointer
That's a weird one. The clientData handle there is not used to specify a mount point, but rather a separate capability of the filesystem type. Tcl's internal use of Tcl_FSRegister doesn't use it at all. The code which is as close as anything to a canonical use of it is the tclvfs package.
https://github.com/tcl-mirror/tclvfs/blob/master/generic/vfs.c#L385 shows us the use:
static void
Vfs_RegisterWithInterp(interp)
Tcl_Interp *interp;
{
ClientData vfsAlreadyRegistered;
/*
* We need to know if the interpreter is deleted, so we can
* remove all interp-specific mounts.
*/
Tcl_SetAssocData(interp, "vfs::inUse", (Tcl_InterpDeleteProc*)
Vfs_UnregisterWithInterp, (ClientData) 1);
/*
* Perform one-off registering of our filesystem if that
* has not happened before.
*/
vfsAlreadyRegistered = Tcl_FSData(&vfsFilesystem);
if (vfsAlreadyRegistered == NULL) {
Tcl_FSRegister((ClientData)1, &vfsFilesystem);
Tcl_CreateExitHandler(VfsExitProc, (ClientData)NULL);
Tcl_CreateThreadExitHandler(VfsThreadExitProc, NULL);
}
}
As you can see, the clientData there is really just being used as a marker so the code knows whether to do one-time initialisation.
To discover what the mount mapping is, you'll need to keep internal structures. You're strongly recommended to make the Tcl_Filesystem structure instance itself be global (or rather static at file scope) in your code.

Allocating memory for struct within a struct in cycle

I'm working on INI-style configuration parser for some project, and I gets next trouble.
I have 3 structures:
typedef struct {
const char* name;
unsigned tract;
int channel;
const char* imitation_type;
} module_config;
typedef struct {
int channel_number;
int isWorking;
int frequency;
int moduleCount;
} channel_config;
typedef struct {
int mode;
module_config* module;
channel_config* channel;
} settings;
And I have function for handling data in my INI-file (I working under inih parser): [pasted to pastebin cause too long]. Finally, in main(), I did the next:
settings* main_settings;
main_settings = (settings*)malloc(sizeof(settings));
main_settings->module = (module_config*)malloc(sizeof(module_config));
main_settings->channel = (channel_config*)malloc(sizeof(channel_config));
if (ini_parse("test.ini", handler, &main_settings) < 0) {
printf("Can't load 'test.ini'\n");
return 1;
}
In result, binary crashes with memory fault. I think (no, I KNOW), what I'm incorrectly allocating the memory in handler(), but I does not understand, where I do it wrong. I spent all night long trying to understand memory allocating, and I'm very tired, but now me simply interestingly, what I'm doing wrong, and HOW to force this working fine.
P.S. Sorry for ugly english
The problem seems to be related to the reallocation of your structs:
pconfig = (settings *) realloc(pconfig, (module_count + channel_count) * sizeof(channel_config));
pconfig->module = (module_config *) realloc(pconfig->module, module_count * sizeof(module_config));
pconfig->channel = (channel_config *) realloc(pconfig->channel, channel_count * sizeof(channel_config));
First of all, you must not reallocate the main settings struct. Since your handler will always be called with the original pconfig value, the reallocation of the module and channel arrays has no effect, and you'll access freed memory.
Also when reallocating the module and channel arrays you should allocate count + 1 elements, since the next invocation of handler might assign to the [count] slot.
So try to replace the three lines above with:
pconfig->module = (module_config *) realloc(pconfig->module, (module_count + 1) * sizeof(module_config));
pconfig->channel = (channel_config *) realloc(pconfig->channel, (channel_count + 1) * sizeof(channel_config));

Best practice for managing allocated variables when writing a small library

I'm currently writing a little library of secure char and secure list (just .c/.h files that I will add to future projects) and something is bothering me, I know that some of you will think it is subjective but I think there is a "real" best way to do it. I've searched but there is nothing that give me a close answer. Here is a sample of my code.
The struct and functions used :
typedef struct _secure_list
{
cookie secret; // MUST be set to Cookie
secure_char * schar;
struct _secure_list * next;
} secure_list;
typedef struct _secure_char
{
int length; // number of characters in the string
char * str; // the string (no \0 byte at the end of the string)
} secure_char;
/**
* Create a secure list with schar
* Initialize Cookie on first use
**/
ret_value createSecureList( secure_char * scIn, secure_list ** slist )
I think there is two possible ways to write the createSecureList function :
// FIRST WAY
ret_value createSecureList( secure_char * scIn, secure_list ** slist )
{
(*slist) = NULL;
(*slist) = (secure_list *) malloc( sizeof(secure_list) );
// we copy the secure_char so it can be freed in the caller
createSecureChar("",&((*slist)->schar));
concat2SecureChar(&((*slist)->schar), scIn);
...
 }
// SECOND WAY
ret_value createSecureList( secure_char * scIn, secure_list ** slist )
{
(*slist) = NULL;
(*slist) = (secure_list *) malloc( sizeof(secure_list) );
(*slist)->schar = scIn;
...
 }
In my main() I have :
void main()
{
secure_list * slist_Test;
secure_char * schar_Test;
....
createSecureChar("test test",&schar_test);
createSecureList(schar_Test,&slist_Test);
....
}
My problem is that despite the fact the second way is easier to code and understand, the secure list which is a linked list will point to the same memory space as schar_Test, so if we free one of them, we free both. The first way basically create a copy of schar_Test so it can be freed in the calling function.
Can someone tell me which is the "right" way ?

Is my method of passing a struct as both value and reference correct?

I have looked at the examples of passing a struct by both value and reference. My code compiles but is not working as it should. I am using C to program a micro-controller so it is hard to check if it is working properly, but I am not getting the desired output.
So, as per instructions, I first define my structure:
struct package //define a structure type called package.
{
unsigned char
wavType,startFreq1,startFreq2,startFreq3,startFreq4,
stopFreq1,stopFreq2,
stopFreq3,stopFreq4,step,dura,amp,sett; //define bytes to use
};
In the main method I create an instance of it:
struct package p; //create a new instance of Package
Now I pass it by reference (pointer - because I'm using C) to a function:
getPackage(&p);
Within the function getpackage() I update the values of the respective elements of p:
getPackage(struct package *p) //Get data package
{
p->wavType = receive();
p->startFreq1 = receive();
p->startFreq2 = receive();
p->startFreq3 = receive();
p->startFreq4 = receive();
p->stopFreq1 = receive();
p->stopFreq2 = receive();
p->stopFreq3 = receive();
p->stopFreq4 = receive();
p->step = receive();
p->dura = receive();
p->amp = receive();
p->sett = receive();
}
This is the receive function:
unsigned char receive(void)
{
unsigned char dataR = 0x00;
for(signed char i = 0; i <=7 ;i++)
{
dataR |= PORTBbits.RB1 << i; //move the value on the data pin to a bit in dataR
}
return dataR;
}
QUESTION: Will this correctly update the bytes in the package p? Also, does package p need to be returned if I want to use it elsewhere? I ask this because....
I now pass the package p, by value, into another function using:
sendSine(p);
This function makes use of the value of the bytes in the package p:
void sendSine(struct package p)
{
dataL = p.startFreq1;
dataH = p.startFreq2;
send(dataL,dataH);
dataL = p.startFreq3;
dataH = p.startFreq4;
send(dataL,dataH);
}
I know the function send(dataL,dataH) is working because I have tested it by setting dataL and dataH by hand and I get the required result, so there must be an error along the way with the struct - I just cant figure out where... Can anyone help me with were it might be?
The receive function seems to be the procedure in question. Try writing a stub-replacement for receive, such as:
unsigned char receive(void)
{
unsigned char X = 'a';
// or whatever value you want to simulate as being received
return X;
}
and then try running your complete application, tf it works then go back and re-think your original receive per some of the comments that have already been made.

Resources