Date: Fri, 14 Mar 2014 20:18:20 -0400 From: Walt Ford <walt.ford@yahoo.com> To: =?utf-8?B?5pyx5rGf?= <mail.jiang.cn@gmail.com> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Overhaul the config system with Lua Message-ID: <20140315001820.GB5765@nbu> In-Reply-To: <CAA_8tFojhn66ZkaR_Bxzv3fMzbuc6o2J9fYe4-pW6X0skgA8=Q@mail.gmail.com> References: <CAA_8tFojhn66ZkaR_Bxzv3fMzbuc6o2J9fYe4-pW6X0skgA8=Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 15, 2014 at 01:11:03AM +0800, 朱江 wrote: > I want to overhaul the config system with Lua, and it will be my GSoC 2014 > project. Here is the > proposal<https://docs.google.com/document/d/1azZm8WHBiT_oaQ1fEhUWGiYWyn4hvwxEkMXqf1aR00g/edit?usp=sharing> That's an excellent project. I've had Lua in my own base system for years and have converted the rc system to use it at various times, along with some base utilities. I've been considering posting a Kickstarter project to finally finish it all, but Lua isn't the most popular language, and FreeBSD isn't the most popular OS. The main goal of my work was to present a more uniform userland. Everybody hacks on the kernel, but userland gets a little ignored. There's not much uniformity between command-line options, interactivity, color, scriptability, layout, and naming of utilities, and Lua was a great fit to clean it up. I even got it to the point of generating utilities on its own. When Robert Watson imported audit(2) it was able to crawl the headers and generate a utility in the style of top(1) that showed the most active audit record types as colorized output like gstat(8). Lua could get to the point where it automatically generates entire applications with uniform command-line options, interactivity, color, and scriptability, just based on kernel subsystem definitions in header files plus a little glue. Unfortunately, I've never had the time or money to finish it all. That audit utility is dated 2007. > I will create a wiki in my site soon. Please let me know if you have any > good ideas about the new config system. They will not be a part of my GSoC > project, however, I will do this work continuously after GSoC. I converted a lot of FreeBSD to Lua, but never config(8). Some build issues to figure out how to solve are: * the differences and sloppiness in how userland and kernel options are handled kernel options are manually documented in sys/conf/options* and have no man page share/examples/etc/kern.conf doesn't exist userland options are documented in tools/build/options and the man page, src.conf, is generated using a shell script share/examples/etc/src.conf doesn't exist share/examples/etc/make.conf is manually updated and often out-of-date * generate GENERIC config files currently things are copied and pasted for every arch would need to account for DEFAULTS * automatic generation of OptionalObsoleteFiles.inc must be manually updated and has never been complete a make target could build twice with and without option then find the missing files probably a better job for jenkins and make, but Lua could help I'm sure there are other ways to improve the build system as a whole using Lua, as long as you don't confine yourself to reimplementing config(8) only. The information about options currently stored in tools/build/options and sys/conf/options should really be part of config(8), along with the architecture information necessary to generate documentation or source files automatically. Lua would make a great kernel language as well, another one of the projects I started and haven't had time to play with. -- Walt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140315001820.GB5765>