Re: native inotify implementation

On Fri, 4 Jul 2025 18:14:20 -0700
Rick Macklem <rick.macklem@gmail.com> wrote:

> > Yes, and no. While it's often useful in short-term perspective, such
> > approach leaves FreeBSD without unique features so it becomes yet another
> > "Linux, just poorer" with obvious then "why choose it?". It's
> > understandable that in some cases it is simple to implement compatible
> > API, but an alternative like "have more general solution with a
> > compatibility shim layer via which their API is implemented" is better,
> > when possible.
> >
> > It's late in which particular topic as commit was landed, but for future we
> > should think how to extend kqueue to be able more.
> > [E.g. I'd want to have notifications for my protocol with multiple streams
> > inside one socket (think like QUIC), but it does not fit nicely into
> > current struct kevent or socket API (multiple socket buffers with separate
> > reading)]  
> The flip side of this is "Why would anyone build a significant open
> source software
> project that uses a FreeBSD specific API and cannot be built for Linux
> systems?".
> 
> Basically, 99.999% (just a guess) of the open source systems out there are
> Linux based and, as such, open source software projects will be built to use
> their APIs. imho.
> 
> A "more general solution" almost no one will use is not particularly
> useful, again
> imho. 

That's exactly what I'm talking about - if we have no unique features, then
choices will be in favour of Linux, and as a consequence if everybody will
choose Linux, then why we have a reason to exist at all?

So this bad chain should be broken at the beginning.

-- 
WBR, @nuclight