>>>> 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. >>> >>> The problem with your approach is that such "chicken-and-egg" problems >>> are to be solved _at_once_ rather than laying "eggs" everywhere around >>> and have everyone else wait till at least one "chicken" appears. >> >> No. I'm talking about put just one egg, just a device driver. > > Sorry, but this is not "just one egg". "And counting" was your reaction > to complaints that almost all the code related to Lua is the code to > support Lua itself rather than anything else.
"And counting" == there is ongoing work happening outside the tree. >>>> Sure, we do not *need* a script language interpreter embedded in the >>>> kernel, as we do not need a specific file system. But I do not get why >>>> we should not. There is current development of applications being done >>>> right now. Also, there is a few interesting works that used Lunatik in >>>> Linux [1, 2] that could be done more easily now in NetBSD just because >>>> we have the right environment for that. 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?). I think that is why we *should* (not need) >>>> have this on the tree. IMHO. >>> >>> I have to point out that "interesting work" is commonly used as a sort of >>> euphemism to refer to highly experimental work with unclear future. >> >> Yes. But I'm talking about "interesting *user* work". I'm not claiming >> that they should be in the kernel. I'm just saying that, IMHO, we >> should incorporate a small device driver that facilitates this kind of >> development (outside the tree). > > I'm of opinion that this device driver can and should stay outside the tree > until its utility can be demonstrated without this much strain. > At last this is one of the reasons why we support kernel modules. Understand. >>> You tell that there's "interesting work" using Lua in Linux. >>> Was it accepted in any experimental Linux distribution like Fedora? >>> What was the outcome of discussion among linux kernel developers? >>> Currently there's no indication that it was accepted anywhere. >> >> Really don't know. I'm not a member of these communities neither I'm >> claiming to incorporate such works here. However, I think that there >> was a discussion about PacketScript on OpenWRT, but I don't know how >> it evolved. > > This demonstrates that Lua isn't actually useful in the kernel. I don't think so. It could even evince that, but not demonstrate. >>> And last. The appeal to "why not" is defective. NetBSD is not your >>> personal playground, there exist other people who have to deal with >>> the inadvertent mess you can leave after you. That's why you ought >>> to present solid arguments that justify why other people should tolerate >>> your experimentations. >> >> I guess you misunderstood that. I'm not arguing that we should do it >> just because there is no contrary argument. I sincerely asked 'why >> not?' trying to understand the contrary argumentation. Also, I'm not >> saying that you should tolerate my experimentation. Far away from >> that. I haven't committed anything nor tried to impose nothing. > > On my side it sounded like that, sorry, if I'm wrong. It could sound as you want, but it wasn't what I meant. >> I'm >> just trying to make a point of view and understand yours. When I >> talked about experimentation, I was trying to say that providing >> support for that kind of experimentation for users sounds a good idea >> for me and I don't see how it is prejudicial. Which doesn't mean that >> I'm proposing that my personal experimentation should be in tree. > > The problem as I see it is that we have one developer (two at most) > pushing hard for Lua in base and in kernel and providing no satisfactory > arguments why this is to be done at all. Lack of any real code for years > reinforces such doubts. > > "Why not" sounds as an argument for highly experimental work in this context. > And I wouldn't have anything against this "why not" if all the work were > dressed accordingly. For now I'd say that Lua support hasn't demonstrated > any benefit. I'd say that it should be removed and the work continued > in a branch until benefits become more clear. Understand. Regards, -- Lourival Vieira Neto
