Subject: Re: OpenVPN
To: Sanjay Shridhar <>
From: Bill Studenmund <>
List: tech-net
Date: 05/11/2006 18:48:32
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 11, 2006 at 01:25:22PM -0700, Sanjay Shridhar wrote:
> =20
> > From: Bill Studenmund []=20
> > Subject: Re: OpenVPN
> >=20
> > On Thu, May 11, 2006 at 10:42:40AM -0700, Sanjay Shridhar wrote:
> > > =20
> > > > [] On Behalf Of der Mouse
> > > >=20
> > > > Depends on how OpenVPN uses it.  But, looking at the code for=20
> > > > SIGPIPE generation, it looks as though this would be dead easy to=
> > > > add to NetBSD.  sendit(), in uipc_syscalls.c, is the only place tha=
> > > > I think needs to be touched:
> > > >=20
> > > > -                if (error =3D=3D EPIPE)
> > > > -                        psignal(p, SIGPIPE);
> > > > +                if ((error =3D=3D EPIPE) && !(flags & MSG_NOSIGNAL=
> > > > +                        psignal(p, SIGPIPE);
> > >=20
> > > If you do this, you would have version compatibility=20
> > issues. Maybe a=20
> > > nice additional feature, but increases the burden on the=20
> > app space to=20
> > > be compatible between versions that do and don't support this.
> >=20
> > Huh?
> >=20
> > How would adding support for MSG_NOSIGNAL to NetBSD cause=20
> > compat issues?=20
> > OpenVPN isn't compatible with NetBSD without this; the app=20
> > isn't burdened with supporting NetBSD w/o this feature.
> Let's say you write a new application that requires similar kernel
> facilities like OpenVPN does and let's say the new app writer sees this
> documentation on MSG_NOSIGNAL and lets say he goes in and puts in this
> support and the app works great on the version of netbsd that does support
> this feature. So what happens to the app on older versions of netbsd -- t=
> feature doesn't essentially work. So the app writer has to add extra code=
> make it compatible. Else he has to use the least common denominator and n=
> use this feature. Either way the feature is useless or requires more work=
> the app space.

You're honestly suggesting that we NOT add a feature, because someone
would have to conditionalize around its use in applications that wanted to
use it and also run on versions of NetBSD that didn't have it???

Given that criteria, how could we EVER add a new feature?

> The right fix would be to fix the original OpenVPN source code to make it
> portable across Unices (like someone suggested by handling the signal) --
> not fix netbsd so that OpenVPN works unchanged -- you are trying to fix t=
> wrong end. Sure you make netbsd compatible to other linux/freebsd in the
> long run, but to me it seems like this is not worth it.

There are standards, such as POSIX and the SUS, that define a common base=
of unix functionality. Actually, a common base of OS functionality, since=
Windows can support many of them. If an application developer (or=20
developers) decide to make the program very portable, they need only (and=
must only) use explicit POSIX or SUS functionalty.

However I see no reason where it is either your or my (or anyone else on
this list's) place to TELL the author of another application, which we
wish to port to NetBSD, that said application MUST be made POSIX/SUS

Also, have you ever used SIGPIPE? It's great if you have a bunch of=20
commands piped together on a shell command line. One of them goes down,=20
the whole chain goes down. Which usually is what you want.

However if you're working with a server (daemon), you really don't want it=
at all. Your connections will go away, but you don't want that to kill=20
your app. So you have to ignore SIGPIPE.

This change makes a lot of sense to me. 1) it lets an app ignore SIGPIPE=20
some of the time but not all the time. 2) There also is the asthetic=20
beauty of having the kernel never generate a signal you KNOW you will=20
never use. :-)

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)