rename lunatik bindings from lua<libname>.c to luna<libname>.c

[lneto]

this is only a suggestion, we can discuss it; but I think it will make it easier to find and manage our bindings. E.g., it would be easier to find our loaded modules using lsmod | grep luna.

[iammuntazirali]

I can work on this. Please assign it to me.

[iammuntazirali]

Issue #414: The Problem

Lunatik is a framework that lets you run Lua scripts inside the Linux kernel. It provides ~25 "binding" modules that give Lua access to kernel features like:

• Device drivers (

  luadevice

  )
• Sockets (

  luasocket

  )
• Cryptography (

  luacrypto_*

  )
• Network filtering (
  luanetfilter)
• etc.

The Exact Problem:

All these binding files are named with a 

lua prefix:

lib/luadevice.c
lib/luasocket.c  
lib/luacrypto_shash.c
lib/luanetfilter.c
... (25 files total)

When compiled, these become kernel modules like 

luadevice.ko

, 

luasocket.ko

, etc.

The issue: When a sysadmin wants to find Lunatik's loaded modules using:

bash
lsmod | grep lua

They get ALL Lua-related modules mixed together, making it hard to identify which ones belong to Lunatik specifically.

---

The Solution

Rename all binding files from 

lua<name>

 to 

luna<name>

:

Before | After -- | -- luadevice.c | lunadevice.c luasocket.c | lunasocket.c luacrypto_shash.c | lunacrypto_shash.c ... | ...

Now sysadmins can easily find only Lunatik modules:

bash
lsmod | grep luna    # Shows ONLY Lunatik modules!

[lneto]

we meant to have more human discussion here.. what's the disadvantages you see in this case? what's the benefits? the problem is not what you (or the bot) described as:

They get ALL Lua-related modules mixed together, making it hard to identify which ones belong to Lunatik specifically.

[iammuntazirali]

Thanks for opening this discussion!

---

Benefits:

• The luna* prefix establishes a clear Lunatik identity and avoids confusion with generic Lua modules.
• It improves discoverability for system administrators (e.g., lsmod | grep luna cleanly lists Lunatik modules).
• The naming aligns naturally with the project name (Lunatik → luna).
• It clearly signals that these modules are kernel bindings rather than userspace Lua libraries.

Potential drawbacks:

• This introduces a breaking change for users with existing scripts or configurations that reference the current module names.
• Documentation and examples will need to be updated to reflect the new naming.
• External tutorials, blog posts, or tools that mention the existing module names may become outdated.

Overall, the long-term clarity and maintainability benefits seem to outweigh these drawbacks. That said, are there known users or downstream projects that rely on the current naming and should be considered before moving forward?

Happy to discuss further, or I can proceed with the implementation if this direction looks good.

[lneto]

please, see my comments on your PR as well.. you are not using git mv on most of the modules.. also, it's not clear that you have tested your patch.

[lneto]

• The luna* prefix establishes a clear Lunatik identity and avoids confusion with generic Lua modules.

which ones? it's not clear to me.

• It improves discoverability for system administrators (e.g., lsmod | grep luna cleanly lists Lunatik modules).

how so? it's not clear to me as well.

• This introduces a breaking change for users with existing scripts or configurations that reference the current module names.

how so? it's not clear to me as well.

• Documentation and examples will need to be updated to reflect the new naming.

Overall, the long-term clarity and maintainability benefits seem to outweigh these drawbacks. That said, are there known users or downstream projects that rely on the current naming and should be considered before moving forward?

mostly our openwrt feed.

[kishansinghifs1]

Hiii @lneto what I understood from the above conversation and comments on the PR is we achieve the lsmod | grep luna by only changing the Kbuild output module names, without renaming the source files ? was it the only scope you were up for discussion or is there something else too ?

[lneto]

Hiii @lneto what I understood from the above conversation and comments on the PR is we achieve the lsmod | grep luna by only changing the Kbuild output module names, without renaming the source files ? was it the only scope you were up for discussion or is there something else too ?

Hi, this issue is to actually evaluate pros and cons; please see my comments regarding this above. The idea was indeed to rename the files and clean up the namespace. However, I changed my mind, I don't think it's a good first issue. The execution might very straightforward, but it demands more thourughtful evaluation. I'll remove the tag. If you're looking for a good first issue, I recommend the one for fixing stat on config.lua.

[kishansinghifs1]

Hiii @lneto is this the issue you have been talking about #435.