On portable C programming (was: libraw1394 struct layouts...)
Jim Kuzdrall
gnhlug at intrel.com
Thu Jan 8 12:33:33 EST 2009
On Thursday 08 January 2009 11:25, VirginSnow at vfemail.net wrote:
>
> While this could work for userland code, you might run into trouble
> in kernel code. How would you access the "struct library" from the
> kernel? And (more importantly!) how would you convince the kernel
> developers to adopt such a practice?
>
> Perhaps, if the universal<->native translation was done by a
> preprocessor, you could have say scsi_ioctl.uni -> scsi_ioctl.h,
> which could then be #included in the source. That might be a little
> less cumbersome.
>
> I don't think having *.uni->*.h would solve endian issues, but endian
> issues generally aren't a problem in the kernel. (With some notable
> exceptions: struct udphdr, struct nbd_request, etc.)
My outline over-complicated the solution - no pointer array is
needed. If the addresses of the structs are be obtained from the
kernel while it is running, the data can be sent to or taken from them
to an external "universal" format. At the very worst, this would
require a compile header which allocates extern pointers equated to the
run-time struct addresses. The translation functions can be compiled
with the kernel or in a linked library, but they don't need any changes
to the existing kernel code.
Admittedly, most of the code I have written over the years has been
for use without an operating system - speed and real-time processing
were always critical. But, if I understand the problem correctly, it
should not be necessary to mess with the kernel or the kernel
developers.
Jim Kuzdrall
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
More information about the gnhlug-discuss
mailing list