Re: git: af93fea71038 - main - timerfd: Move implementation from linux compat to sys/kern

On Mon, Aug 28, 2023 at 3:27 PM Kyle Evans <kevans@freebsd.org> wrote:

> On 8/28/23 16:12, Jake Freeland wrote:
> > On Mon, Aug 28, 2023 at 11:19 AM Warner Losh <imp@bsdimp.com
> > <mailto:imp@bsdimp.com>> wrote:
> >
> >     Added cc for Jake
> >
> >     On Mon, Aug 28, 2023 at 6:17 AM Alexey Dokuchaev <danfe@freebsd.org
> >     <mailto:danfe@freebsd.org>> wrote:
> >
> >         On Thu, Aug 24, 2023 at 08:29:48PM +0000, Warner Losh wrote:
> >          > commit af93fea710385b2b11f0cabd377e7ed6f3d97c34
> >          >
> >          >   timerfd: Move implementation from linux compat to sys/kern
> >          >
> >          >   Move the timerfd impelemntation from linux compat code to
> >         sys/kern.
> >
> >         Could you quickly summarize why we need these linuxish bits in
> >         FreeBSD?
> >         We've lived for years without it.  Had expected to find the
> >         rationale
> >         in DR but alas. :(  Thanks,
> >
> >
> > The amount of software designed exclusively for Linux grows every day.
> > Support for FreeBSD is almost always done on behalf of FreeBSD
> > contributors, not the program developers.
> >
> > I do not want to play the cat-and-mouse game of constantly updating
> > shims so we can support Linux software. I would rather take the
> > sensible* parts of Linux and integrate them into core FreeBSD.
> >
> > My goal is not to turn FreeBSD into Linux, but rather to stay relevant
> > in an age where most younger developers don't even know what BSD is. We
> > should spend more resources on Linux program support, so younger
> > audiences can use their Discord web apps natively on FreeBSD.
> >
> > Absorbing "linuxish" bits is controversial and I think that is a
> > tragedy. In my eyes, having "linuxish" features is one of the best ways
> > to ease the jump between Linux and FreeBSD, and minimize the maintenance
> > needed for FreeBSD support.
> >
>
> +1. We're not in the game of adopting Linuxisms for the sake of it, but
> rather where they make sense (either they're obviously a good thing, or
> they simply make it easier to write portable scripts/code without
> damaging the quality of our code, like long options).
>
> Remaining different for the sake of remaining different is way more
> silly than adopting sensible features.
>

I agree with both points. In the early days (1.x-4.x) days we were rather
proud we were NOT Linux. However, it set a bad precedent. Most of the
new items that POSIX is standardizing, for example, come from Linux. Much
of the software out there depends on these Linuxisms. In large part, over
the past 5-10 or so years I've noticed the project has generally been more
accepting of including Native version of Linux APIs (command line, system
calls, glibc extentions, etc) to make it easier to just take a random bit
of code off the net and use it. It's pragmatic more than anything else. It's
motivated in large part for high-demand items (like Discord client), but
it has the effect of lowering barriers to entry for people using FreeBSD.

timerfd is one of these things that makes a lot of the 'special case' code
for things that aren't file descriptors less half-baked. In many ways, this
is
very Unixy (old-school everything is a fd). While there are issues with
everything
as a 'fd' at times, there's many times, like event propagation, where the
ability to view anything as a fd is quite powerful. That won't mean the only
way to do timer things are via a fd (dodging much of the objection to people
trying to make everything a fd: it's too artificial). In this case, it
bridges the
domain rather than imposes a dogmatic view that everything has to *BE* a
fd. Just convertible to a FD. timerfd is one of many ways to do this. As
someone
that wrote

This also doesn't interfere with the old FreeBSD ways...

So that's why I went ahead and committed this. It's a de-facto standard that
things need/want and it's nice to have some of the same tools that Linux
has natively in FreeBSD. Linux stole Unix's system calls in the old days
and created a fork of the Unix way. It's innovated, and it would be silly
to ignore that innovation just because it was in Linux.

And I totally acknowledge there were some issues with the import. I
accept responsibility for not catching them. thankfully, Jake is working
to address them and we have enough time before 14.0. I'm also making
notes for what to do differently next time. One is clearly to loop Alexey
into the process: I didn't think about it before the commit, but in
hindsight
it's really something I should have done.

Warner


> > *
> >
> https://ariadne.space/2021/06/06/actually-bsd-kqueue-is-a-mountain-of-technical-debt/
> <
> https://ariadne.space/2021/06/06/actually-bsd-kqueue-is-a-mountain-of-technical-debt/
> >
> > Jake Freeland
> >
>
> Thanks,
>
> Kyle Evans
>
>