> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@netbsd.org] 
> Sent: Thursday, May 11, 2006 12:49 PM
> To: Sanjay Shridhar
> Cc: 'der Mouse'; tech-net@netbsd.org
> Subject: Re: OpenVPN
> 
> On Thu, May 11, 2006 at 10:42:40AM -0700, Sanjay Shridhar wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: tech-net-owner@NetBSD.org
> > > [mailto:tech-net-owner@NetBSD.org] On Behalf Of der Mouse
> > > Sent: Thursday, May 11, 2006 6:52 AM
> > > To: tech-net@NetBSD.org
> > > Subject: Re: OpenVPN
> > > 
> > > >> There is no nonportability here unless they care about 
> > > >> portability across the silent API change (which is 
> unlikely) or 
> > > >> unless
> > > Linux does
> > > >> it gratuitously differently (which is reasonably 
> likely, actually).
> > > > The struct msghdr and function arguments are identical. 
>  However, 
> > > > OpenVPN does use a flag not defined in NetBSD:
> > > 
> > > > MSG_NOSIGNAL
> > > >  	Requests not to send SIGPIPE on errors on 
> stream oriented
> > > >  	sockets when the other end breaks the 
> connection.  The EPIPE
> > > >  	error is still returned.
> > > 
> > > > That doesn't look like a showstopper...
> > > 
> > > Depends on how OpenVPN uses it.  But, looking at the code for 
> > > SIGPIPE generation, it looks as though this would be dead easy to 
> > > add to NetBSD.  sendit(), in uipc_syscalls.c, is the only 
> place that 
> > > I think needs to be touched:
> > > 
> > > -                if (error == EPIPE)
> > > -                        psignal(p, SIGPIPE);
> > > +                if ((error == EPIPE) && !(flags & MSG_NOSIGNAL))
> > > +                        psignal(p, SIGPIPE);
> > 
> > If you do this, you would have version compatibility 
> issues. Maybe a 
> > nice additional feature, but increases the burden on the 
> app space to 
> > be compatible between versions that do and don't support this.
> 
> Huh?
> 
> How would adding support for MSG_NOSIGNAL to NetBSD cause 
> compat issues? 
> OpenVPN isn't compatible with NetBSD without this; the app 
> 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 -- the
feature doesn't essentially work. So the app writer has to add extra code to
make it compatible. Else he has to use the least common denominator and not
use this feature. Either way the feature is useless or requires more work on
the app space.

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 the
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.

- Sanjay

> 
> This feature is also small-enough that it could probably get 
> pulled into the 3.X branch and probably the 2.X branch too.
> 
> Take care,
> 
> Bill
>