Re: Rust: kernel vs user-space
- In reply to: Stefan Esser : "Re: Rust: kernel vs user-space"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 04 Sep 2024 21:11:51 UTC
On Wed, Sep 4, 2024, 10:42 AM Stefan Esser <se@freebsd.org> wrote: > Am 04.09.24 um 17:21 schrieb Bob Bishop: > > Hi, > > > >> On 4 Sep 2024, at 15:37, Stefan Esser <se@FreeBSD.org> wrote: > >> > >> Am 04.09.24 um 11:52 schrieb Mark Delany: > >>> On 04Sep24, David Chisnall apparently wrote: > >>>> There are lots of control-plane things that I'd love to see > >>>> written mostly in Lua, > >>> It was remiss of me to not mention Lua given that it's already in the > project. > >>> Yet another language which could make life easier, more productive and > more accessible in > >>> user-land. > >>> I'm not suggesting for an instant that any of these programs need > rewriting, but one could > >>> imagine that if commands like ifconfig, route, arp, ndp, ipfw (that > is, programs which > >>> take a lot of user input and do a lot of data manipulation but aren't > super-critical on > >>> the performance front) were written in a more accessible language, > then it might attract > >>> new developers without disenfranchising the core C developers. > >> > >> Here is ldconfig in LUA, written more than 2 years ago, for example: > >> > >> https://github.com/stesser/ldconfig/blob/main/ldconfig.lua > > > > And this is better than C because ...? > > > > (Asking for a friend :-) > > There had been a request for an architecture independent implementation > that works on all FreeBSD releases and architectures. > > The LUA run-time has been available in FreeBSD for a long time, and it > is a stable platform suitable for the implementation of commands that > operate on text and might take advantage of features like associative > storage. It is a "safe" implementation since memory is automatically > managed, which reduces the risk of memory management errors (but we > have to trust the LUA interpreter to be free of such issues, instead). > > I have not made this version available for review (but instead updated > the C version to work with hints files of either byte order). But this > code is much simpler than the C version it replaces, and it could easily > be extended to, e.g., prepare hints files in chroot environments or in > images prepared for an architecture with a (possibly) different byte order. > > And it is not only independent of the byte order and portable over all > architectures, but also independent of the FreeBSD version. > > The LUA version is much shorter and easier to understand (if you know > LUA), but one reason not to propose it for inclusion in FreeBSD is that > there are many more developers that know how to work on the C version > than on the LUA version. > > David and Mark have mentioned LUA, and there is little LUA code in the > base system, currently (mostly the loader). I'd like to see LUA being > used for more functionality that is not time critical, and since the LUA > language has been very stable over time (other than many other interpreted > languages), it is unlikely that a LUA script will not work on a later > FreeBSD release (it only depends on a working flua and possibly some > LUA include files). > I do most of my string processing code in lua these days. I think this reimplementaion makes sense: it helps in cross building. I have a config successor doodled out in lua... Warner Anyway, this is off-topic for the discussion about rust, other than > that LUA is a language that is not affected by many bugs that are > typical for programs written in C. > > Best regards, STefan > >