>>> Lua is a tool, not an end in itself. I think that you are formulating >>> a chicken-and-egg problem: we need the basic support for then having >>> applications, and we need applications for then having basic support. >>> >>> This is not a chicken-and-egg problem. You can make an experimental >>> kernel with Lua support and make an experimental application in Lua, >>> all before anything has to be committed to HEAD[*]. Then you can show >>> that the application serves a useful function, has compelling benefits >>> over writing it in C, and can offer confidence in robustness. >>> >>> [*] You could do this in a branch, you could do this in a private Git >>> repository, or you could even just do this in a local CVS checkout >>> (since kernel Lua requires no invasive changes, right?). >> >> Yes, but how do we do device driver development? We are branching the >> tree for each non-intrusive and disabled-by-default device driver? If >> we have developed a device driver for an uncommon device, we have to >> put it in a branch? (Please, note I'm friendly asking that). > > We didn't import yet another programming language interpreter for driver > development previously. Besides, what are drivers developed in Lua so far? > If I understand it correctly, the only driver is the Lua interpreter itself.
I meant traditional device driver, but never mind. >>> That is not about needing, but it is about supporting a certain >>> kind of agile development, prototyping, customization and >>> experimentation in the NetBSD kernel (how could it be hurtful?). >>> >>> Prototyping and experimentation is great! Show examples! What hurts >>> is getting bitrotten code that nobody actually maintains or uses (when >>> was the last Lua update in src?) and provides a new Turing machine >>> with device access in the kernel for attack vectors. >> >> I don't see how an optional module could be used for attacks. If users >> enable that, they should know what they are doing (such as loading a >> kernel module). > > Was anything done to warn users? The code is not linked yet. Regards, -- Lourival Vieira Neto
