[syslinux] [PATCH 0/2] improve Lua API for files and initramfs objects

[H. Peter Anvin]

On 11/20/16 00:13, Ferenc Wágner via Syslinux wrote:
> 
> This indeed copies the data from the syslinux_file structure (which is
> an opaque SYSLINUX_FILE object on the Lua side) into an (interned) Lua
> string to make it available to the Lua string functions.
> 
> You probably ask why we copy the data when we create those SYSLINUX_FILE
> userdata objects.  We don't, the data is read directly into the
> syslinux_file structure by the loadfile() Syslinux function.  This was
> already the case when I first saw the Lua binding in Syslinux.  Thinking
> about it now, the SYSLINUX_FILE userdata objects and their entire
> interface could be replaced by Lua tables with two string fields for
> much the same effect, unless the native Lua string I/O is much less
> efficient than loadfile().  If we can drop the name method, even simple
> Lua strings would suffice.  The complication arises when you assemble
> initramfs objects incrementally: either you'll have to copy the data, or
> keep a reference to each constituent Lua string and delay creating the
> actual initramfs structure until its point of usage (and destroy it if
> you somehow fail back to Lua).  This might be worth exploring.
> 

This seems like a very sensible approach to me.  Keeping a reference and
just pointing into the Lua memory representation makes a lot more sense.

[f]loadfile() is "smart" in the sense that if, and only if, the size of
the file is known ahead of time it allocates the buffer in one shot,
rather than using realloc().  Do note that [f]loadfile() (as opposed to
initramfs_load_file()) just loads data into a memory buffer.  If there
is a way to represent a memory buffer allocated by C as a Lua string
that would pretty much take care of the same thing.  floadfile() even
allows a chunk of data to be prepended to the buffer, which could be
useful in the case of a Lua string needing something prepended to the
data buffer.

Creating struct initramfs at the point of execution seems reasonable,
but on the other hand, is there a reason we can't simply add a reference
to the Lua string and let it be referenced by struct initramfs using
initramfs_add_file()?  The main shortcoming I see with that is the
object is opaque, and it could be nice to be allowed to examine it, but
that seems like a second-order feature.

	-hpa