Post by John BaldwinPost by Warner LoshPost by Andriy GaponPost by Andriy GaponPost by Ian LeporeIirc, the big difference between 5.2.x and 5.3 is that the latter added
support for integers. It seems like that would be a good thing, in the
kernel.
I am sure that the ZFS Lua represents numbers as integers and has no
floating
Post by Andriy Gaponpoint support at all.
https://github.com/illumos/illumos-gate/blob/master/usr/
src/uts/common/fs/zfs/lua/README.zfs
Reading this strongly suggests to me that we're going to have two versions
1) This version is a modified version of 5.2.4
2) Significant changes have been made to harden this interpreter, which
won't be in 5.3.0
3) A number of APIs have been removed, which makes it difficult to use as a
general purpose thing.
So I think that you should go ahead and import it. The level of work for my
request is very high, and significantly diverges us from upstream. It's
unfortunate that we'll have two versions. But this isn't really pure lua
but a variant maybe better described as lua-zfs.
Yes, that was my guess from Andriy's original e-mail. ZFS tends to be a bit
self-contained and includes its own version of zlib for example. In general
it seems to use its own version of 3rd party utils rather than sharing those
with other parts of the system.
The zlib situation with ZFS is somewhat different, I think the goal
was to share one copy of zlib in the whole Solaris kernel, and as such
it was implemented as wrapper around regular zlib rather than a fork
like in ZFS. The only reason it was imported this way, if I
understood correctly, is that the zlib in FreeBSD kernel at the time
was too old.
Actually there was an attempt to unify zlib across the kernel a few
years ago, by the way:
https://svnweb.freebsd.org/base?view=revision&revision=199954
I'd be *really* happy to see we unify all zlib users into one,
hopefully with the base userland contrib/zlib. Maybe a good hackathon
goal?
Similar situation applies to the LZ4 compression too, but the change
in LZ4 is more intrusive than zlib: at the time it was added, there is
no other consumers of LZ4, and there was no way to change memory
allocator without making changes to LZ4 code itself (which was fixed
by more recent LZ4 versions). If in the future we decided to have LZ4
in other FreeBSD kernel components, it would be beneficial to unify
them too.
The lua-zfs is different as many pointed out, and I think the benefit
of importing the functionality is great enough to warrant having two
copies of code at the same time, at least as an interim solution.
Cheers,