re: Path to kmods

[matthew green <mrg%eterna.com.au@localhost>]

   That's true but the project moves towards a 'new features, we groom 'em
   and old features we drop 'em without proper discussion first' position;

exactly how?  what are you talking about?  SA?  as much as i
argued for SA syscalls being put back, you're ignoring the work
done to make netbsd-4 binaries work on netbsd-5 systems without
these syscalls being present.  oh yeah, and the syscalls are
there now, so what exactly is the problem?

   I therefore can see what dM is saying, why, and I fear, too, that this
   is going to happen. By the latest developments you can see that we already
   stopped caring about backwards compatibility, from the programmers, the
   system administrators, the packagers and the users view. So what makes you

again, what do you mean?  please give real examples where these
things have happened where backwards compat was not provided
for featurse you care about _on purpose_.

   think that the "hard to groom because 'nobody' uses it" features will
   get fixed? Who is/was fixing the SA bugs? "It's ugly let's drop it". Who
   will notice when a non modular generic is broken? "Everybody should be using
   modules anyways. It's much leaner!" Who notices if XFree gets broken?
   "Use X.Org". Who fixes softdeps? "It is going to be dropped and replaced
   by WAPBL". Who fixes interop issues on systems that do not want IPv6 ?
   "Better get to like IPv6. ENOPATCH. We don't care about IPv4 only systems".
   You can just add "Who cares about static linking" to the list.

again, what are you talking about?

lets go through these one by one:

        SA - it was removed for a time between releases while we
        switched to a new kernel threading and it was put back
        before netbsd-5 branch.  and SA isn't really relevant to
        this.  SA was a back-end for pthreads.  as long as the
        pthread apps continue to work, that's what matters.  this
        point is even more misguided -- we (and by 'we' here, i
        mean andrew doran) worked quite hard to make pthread-using
        apps work on a netbsd-5 system.

        "non modular" - modular code is *the same code* as the non
        modular case.  this is a huge step *forwards* compared to
        the old lkm framework.  it is now easier to obtain this
        goal than before.

        xfree?  who cares?  you want xfree to work?  you go work
        on updating it for netbsd.  xfree86 project is not the
        direction netbsd is taking for our up-stream X provider,
        just like we switched from the XC tarballs to XF86 some
        years ago.  xorg is the new direction and we're working
        *very* hard on it, and making it work with all our old
        supported hardware.

        softdep?  it's never been generally considered useable
        by a large portion of the netbsd community, and has not
        had a maintainer in netbsd for years.  want to try?
        please send patches.

        ipv4-only systems?  i build them every time i build a
        non-GENERIC-style kernel.  sounds like you had a bug that
        only occured in this case?  are you going to claim that
        every bug introduced means that someone else doesn't
        care about your feature?

        static linking?  there has never been a serious proposal
        to remove this from netbsd.  even the rejected proposal
        from thorpej was not about removing static linking, and
        was explicit about leaving that support, but about not
        shipping .a libraries any more _by default_.  it in no
        way was going to remove any support for using or building
        them.

in other words, you, like mouse, are just spreading FUD.

please stop it.

if you want to help these features, and more, from breaking,
then you should be testing these features.  claiming that we
don't care about backwards compat is ignoring the massive
amount of work that all the netbsd developers who have worked
on that have done.  thanks!


.mrg.