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