Merge with my crystalhd branch #16
Conversation
dlenski
left a comment
dlenski
left a comment
There was a problem hiding this comment.
This merge add the linux CONFIG_COMPAT layer (This allows a 32 birs crystalhd library to run on a 64 bits linux kernel)
I'm curious… what's the motivation for this? 64-bit versions of the crystalhd library exist and work fine in my experience.
… and some other fixes.
It appears that a substantial portion of the changes here are to remove unused code paths (several unused variables and a couple unused functions).
This is helpful, but could you rebase these into a separate commit, so that these changes are clearly identifiable?
| pNALU = pStart + Ctx->VidParams.StartCodeSz; | ||
| ulNalSize = Ctx->PESConvParams.m_lStartCodeDataSize; | ||
| // pNALU = pStart + Ctx->VidParams.StartCodeSz; // uint8_t *pNALU = NULL; | ||
| // ulNalSize = Ctx->PESConvParams.m_lStartCodeDataSize; // uint32_t ulNalSize = 0; |
There was a problem hiding this comment.
Looks like these variables were totally unused… is that right?
There was a problem hiding this comment.
Indeed these variables are defined and useless.
The 'compat' layer was very useful in the past when the x86_64 was not the reference. Today I still have a working i686 distribution with some packages not in-sync with their x86_64 counterparts. This is still useful for testing, the i686 packages will run perfectly on the x86_64 kernel. We have too the x32 abi (x86_64 instructions with 32 bits pointer), this layer allows the compatibility too.
There was a problem hiding this comment.
I have updated the branch master on my side; The changes are rebased and separated.
I let you check.
This feature allows a 32 bits crystalhd library to run on a 64 bits linux kernel, and the x32 ABI compatibility too.
2 participants
This merge add the linux CONFIG_COMPAT layer (This allows a 32 birs crystalhd library to run on a 64 bits linux kernel), and some other fixes.