Hello dear List! Unfortunately there is no possibility at the moment to search through list-archives. Perhaps someone could give me an advise. I'd like to communicate with the char device driver which is realised as a file. In C I can just make "dsp_fd = open(dsp_devname, O_RDWR|O_SYNC)" and then work with it all the time using "write(fd, (const void*)msg, nbytes)" and read respectively without additional activities. How should I use it in GPC? The only way I see is to Assign (dsp_fd, dsp_devname) and then Rewrite it when I have to write to and Reset it when I need to read from. Is it the right way from the point of view of the system performance? Or should I better create an interface with file written in C to avoid the Reset and Rewrite operations? Thanks, regards, Igor mailto:marny@rambler.ru
Igor Marnat wrote:
Unfortunately there is no possibility at the moment to search through list-archives.
was :-)
Perhaps someone could give me an advise. I'd like to communicate with the char device driver which is realised as a file. In C I can just make "dsp_fd = open(dsp_devname, O_RDWR|O_SYNC)" and then work with it all the time using "write(fd, (const void*)msg, nbytes)" and read respectively without additional activities. How should I use it in GPC? The only way I see is to Assign (dsp_fd, dsp_devname) and then Rewrite it when I have to write to and Reset it when I need to read from.
Since `Rewrite' by definition truncates a (regular) file, it will reopen it on the system level. However, GPC allows reading and writing from a file opened with `Reset' (by default for typed and untyped files, and for text files if FileMode contains FileMode_Text_Reset_ReadWrite -- see unit GPC; it's a bit clumsy for BP compatibility).
For regular files, you'd have to seek back, but for character devices, this is usually not necessary.
However, GPC's opening routines currently don't support O_SYNC, so if that's essential, you may have to call libc's open directly.
The GPC unit contains low-level file routines such as OpenHandle (also without O_SYNC support though), ReadHandle, WriteHandle (which work with handles obtained from libc's open), AssignHandle (to bind such a handle to a Pascal file) etc.
HTH, Frank
Hello Frank,
FH> The GPC unit contains low-level file routines such as OpenHandle FH> (also without O_SYNC support though), ReadHandle, WriteHandle (which FH> work with handles obtained from libc's open), AssignHandle (to bind FH> such a handle to a Pascal file) etc.
Thank you for the answer. I've forgot that I'll have to make ioctl calls for this device, therefore I'll anyway be forced to write interface functions in C. I've looked at GPC sources and didn't find interface function for ioctl.
Best regards, Igor mailto:marny@rambler.ru
Igor Marnat wrote:
FH> The GPC unit contains low-level file routines such as OpenHandle FH> (also without O_SYNC support though), ReadHandle, WriteHandle (which FH> work with handles obtained from libc's open), AssignHandle (to bind FH> such a handle to a Pascal file) etc.
Thank you for the answer. I've forgot that I'll have to make ioctl calls for this device, therefore I'll anyway be forced to write interface functions in C. I've looked at GPC sources and didn't find interface function for ioctl.
No, ioctl is too diverse to provide a simple GPC wrapper. However, you still can freely mix C and Pascal routines if you work with file descriptors (integer), rather than `FILE *' in C and Pascal file types. That's what I'm doing when working with sound cards, BTW.
Frank