Re: Rust: kernel vs user-space

On Wed, Sep 04, 2024 at 06:42:37PM +0200, Stefan Esser 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.
I do not think that the population of developers who knows LUA vs C
is significant for this example.  But a different aspect is IMO much
more important.

The ldconfig utility is critical to fully configured multiuser FreeBSD
state.  Right now the utility depends on rtld and libc (ignoring the
whole stuff at and below kernel).  So any problem in either of rtld or
libc which prevent ldconfig from run are critical.

If rewritten in LUA, the utility has the same dependencies on rtld and
libc, plus LUA runtime.  Which, by itself, bring in
/usr/libexec/flua:
        libm.so.5 => /lib/libm.so.5 (0x8010b1000)
        libedit.so.8 => /lib/libedit.so.8 (0x8010ed000)
        libprivateucl.so.1 => /usr/lib/libprivateucl.so.1 (0x801129000)
        libc.so.7 => /lib/libc.so.7 (0x80114f000)
        libtinfow.so.9 => /lib/libtinfow.so.9 (0x801552000)
i.e. libm, terminfo, ucl (?), libedit.  Then, flua runtime lives in /usr,
while ldconfig is reasonably located in /sbin.

There are other considerations than just the language accessibility when
we consider the whole system.