Re: CVS commit: src/sys/uvm

2020-07-18 Thread Rin Okuyama

On 2020/07/18 17:30, Jukka Ruohonen wrote:

On Sat, Jul 18, 2020 at 05:19:07PM +0900, Rin Okuyama wrote:

For most (all?) ports, these specifiers are exposed only for
_KERNEL and friends. So, inttypes(*3*) would not be the best
place for them. Currently, I'm not sure where they should be.
/usr/share/misc/style?


Perhaps a new inttypes(9)?  Another option would be a split akin to
types(3).


I prefer to types(3); there already be types only for _KERNEL
namespace. But no strong opinion from me.

Thanks,
rin


Re: CVS commit: src/sys/uvm

2020-07-18 Thread Jukka Ruohonen
On Sat, Jul 18, 2020 at 05:19:07PM +0900, Rin Okuyama wrote:
> For most (all?) ports, these specifiers are exposed only for
> _KERNEL and friends. So, inttypes(*3*) would not be the best
> place for them. Currently, I'm not sure where they should be.
> /usr/share/misc/style?

Perhaps a new inttypes(9)?  Another option would be a split akin to
types(3).

- Jukka


Re: CVS commit: src/sys/uvm

2020-07-18 Thread Rin Okuyama

On 2020/07/16 16:02, matthew green wrote:

thanks!  i'll try to remember we have PRIxPADDR because i
considered looking for it and thought we didn't have it...


My pleasure!

On 2020/07/16 16:10, Jukka Ruohonen wrote:

The whole { PRIxPADDR, PRIxPSIZE, ..., PRIxREGISTER } family
should probably be documented in inttypes(3)?


For most (all?) ports, these specifiers are exposed only for
_KERNEL and friends. So, inttypes(*3*) would not be the best
place for them. Currently, I'm not sure where they should be.
/usr/share/misc/style?

Thanks,
rin


Re: [sctp fix] Re: CVS commit: src/sys/kern

2020-07-18 Thread Maxime Villard

Le 28/04/2020 à 09:16, Luke Mewburn a écrit :

On 20-04-26 18:15, Maxime Villard wrote:
   |  - There was no demonstrated use-case justifying importing it. In addition,
   |major OSes like Windows and macOS do not implement SCTP. There just is 
no
   |demand for SCTP on the market; and on NetBSD, proportionally even less.

SCTP is used in mobile telco environments; the control plane for
3G and 4G networks uses SCTP (or TCP as an option, but mostly SCTP).


That may be true. I am mostly aware of the multimedia use cases.


Le 01/05/2020 à 18:46, m...@netbsd.org a écrit :

We can setup an equivalence: put as much effort into the SCTP removal
proposal as there was for the SCTP introduction proposal.

Since SCTP was just dropped in src without any prior discussion, I don't
think we need any discussion for removing it.


That would be fair, yes.


Le 02/05/2020 à 13:55, m...@netbsd.org a écrit :

I'm sorry for picking on SCTP in particular. Apparently it was added
because it was listed in src/doc/roadmaps.networking (and it's still
listed there).


But this doesn't address your own point, does it. The one-liner in
src/doc/roadmaps/networking gives no explanation on why we would want SCTP
in the first place. It doesn't even say where the code was imported from.

This brings the question of who, exactly, made this list. Several of the
items on this wanted list are actively *not* wanted, as Christos noted in
five of his "Comment[christos]".

At this point there is no doubt that SCTP in the NetBSD kernel has no
future. The only viable option I see is usrsctp:

https://github.com/sctplab/usrsctp

A userland version of the code, but portable, and actively maintained.

While here, notice the crazy buffer overflows that were fixed in it and
are still present in the NetBSD SCTP kernel code... Adds to my point,
that the code is of extremely poor quality.

Maxime