move lualinux_task and lualinux_stat to configure.lua

[lneto]

these flags could be autogenerated on the build time

[lneto]

actually, stat is already on configue.lua, but we need to remove it from lualinux.c; btw, @sneaky-potato, is there any reason you didn't do that on your PR?

also, we should add this composite to configure.lua

        /* user, group, other */
        {"IRWXUGO", (S_IRWXU|S_IRWXG|S_IRWXO)},
        {"IALLUGO", (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO)},
        {"IRUGO", (S_IRUSR|S_IRGRP|S_IROTH)},
        {"IWUGO", (S_IWUSR|S_IWGRP|S_IWOTH)},
        {"IXUGO", (S_IXUSR|S_IXGRP|S_IXOTH)},

parsing OR'ed flags

[sneaky-potato]

actually, stat is already on configue.lua, but we need to remove it from lualinux.c; btw, @sneaky-potato, is there any reason you didn't do that on your PR?

I must have missed it. Because I remember I started that work by keeping the ethernet constants (defined in if_ether.h) in mind.

[Suryansh-Dey]

Hi, I am a interested in GSOC 2026 with LabLua. I want to work on this issue I have a few questions:

1. task constants source header: The TASK_INTERRUPTIBLE, TASK_UNINTERRUPTIBLE, TASK_KILLABLE, and TASK_IDLE constants come from linux/sched.h (kernel-internal), not a uapi/linux/ header. The existing configure.lua specs use uapi/linux/ headers. Should I use linux/sched.h directly in the spec, or is there a preferred approach?

2. Filtering TASK_ prefix: The linux/sched.h header likely defines many more TASK_-prefixed macros beyond the 4 currently exported (e.g., TASK_RUNNING, TASK_DEAD, TASK_STOPPED, etc.). Should configure.lua export all TASK_ constants, or only the specific subset currently in lualinux_task (INTERRUPTIBLE, UNINTERRUPTIBLE, KILLABLE, IDLE)?

3. Composite stat constants: The current lualinux_stat includes composite constants like S_IRWXUGO, S_IALLUGO, S_IRUGO, S_IWUGO, and S_IXUGO, which are defined in kernel-internal linux/stat.h, not in uapi/linux/stat.h (which is already in configure.lua). Should these composites be handled separately, or should I switch the stat spec to use linux/stat.h instead of uapi/linux/stat.h?

4. Access pattern: Currently linux.task.INTERRUPTIBLE works because the flags are registered as a namespace in the C module. After moving to configure.lua, will the generated Lua files be loaded automatically as part of the linux module, or will users need to require("linux.task") separately?

[lneto]

Hi, I am a interested in GSOC 2026 with LabLua. I want to work on this issue I have a few questions:

1. task constants source header: The TASK_INTERRUPTIBLE, TASK_UNINTERRUPTIBLE, TASK_KILLABLE, and TASK_IDLE constants come from linux/sched.h (kernel-internal), not a uapi/linux/ header. The existing configure.lua specs use uapi/linux/ headers. Should I use linux/sched.h directly in the spec, or is there a preferred approach?

Yup, you should just add support for the header which specifies such constants. We shouldn't be restricted to uapi/

2. Filtering TASK_ prefix: The linux/sched.h header likely defines many more TASK_-prefixed macros beyond the 4 currently exported (e.g., TASK_RUNNING, TASK_DEAD, TASK_STOPPED, etc.). Should configure.lua export all TASK_ constants, or only the specific subset currently in lualinux_task (INTERRUPTIBLE, UNINTERRUPTIBLE, KILLABLE, IDLE)?

I think we could expose all; do you see any cons on doing so?

3. Composite stat constants: The current lualinux_stat includes composite constants like S_IRWXUGO, S_IALLUGO, S_IRUGO, S_IWUGO, and S_IXUGO, which are defined in kernel-internal linux/stat.h, not in uapi/linux/stat.h (which is already in configure.lua). Should these composites be handled separately, or should I switch the stat spec to use linux/stat.h instead of uapi/linux/stat.h?

Perhaps it's a better idea to just use linux/stat.h indeed. @sneaky-potato, can you advise on this?

5. Access pattern: Currently linux.task.INTERRUPTIBLE works because the flags are registered as a namespace in the C module. After moving to configure.lua, will the generated Lua files be loaded automatically as part of the linux module, or will users need to require("linux.task") separately?

I think the simplest now is to just force users to require("linux.task"), what do you think? Please, keep in mind that it's part of this task to adjust the code base accordingly.

[sneaky-potato]

3. Composite stat constants: The current lualinux_stat includes composite constants like S_IRWXUGO, S_IALLUGO, S_IRUGO, S_IWUGO, and S_IXUGO, which are defined in kernel-internal linux/stat.h, not in uapi/linux/stat.h (which is already in configure.lua). Should these composites be handled separately, or should I switch the stat spec to use linux/stat.h instead of uapi/linux/stat.h?

Perhaps it's a better idea to just use linux/stat.h indeed. @sneaky-potato, can you advise on this?

Yes, these OR'd flags are defined in the internal linux/stat.h, this header already contains the header uapi/linux/stat.h. So I think just having linux/stat.h (inplace of uapi/linux/stat.h) in configure.lua should do. Because we are using c preprocessor, I think it will pickup all the defined constants.