Re: Rust: kernel vs user-space

From: Warner Losh <imp_at_bsdimp.com>
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
>
>