> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@netbsd.org] 
> Sent: Thursday, May 11, 2006 6:49 PM
> To: Sanjay Shridhar
> Cc: 'der Mouse'; tech-net@netbsd.org
> Subject: Re: OpenVPN
> 
> On Thu, May 11, 2006 at 01:25:22PM -0700, Sanjay Shridhar wrote:
> >  
> > > From: Bill Studenmund [mailto:wrstuden@netbsd.org]
> > > Subject: Re: OpenVPN
> > > 
> > > On Thu, May 11, 2006 at 10:42:40AM -0700, Sanjay Shridhar wrote:
> > > >  
> > > > > [mailto:tech-net-owner@NetBSD.org] On Behalf Of der Mouse
> > > > > 
> > > > > 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.
> 
> 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???

In this case, yes :-)...I guess due to cynicism with dealing with creeping
featuritis in various areas.

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

I would REQUEST the author rather than TELL them I suppose about this one
little thing that would help netbsd. After all it is open source and I am
sure the original authors/maintainers would be open to discussion -- it
might take a while, but it would be possible.

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

Yes, I've had to deal with SIGPIPE.

> 
> 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 your app. So you have to ignore SIGPIPE.
> 

Hmm. This makes sense, yes, and I see where you are coming from. I've never
had to deal with a pipe in the context of a server app. But couldn't you
deal with this by ignoring the signal (I mean there is a current solution to
the problem).

I guess one would have to weigh the benefits of having this feature
available in a future release of netbsd and getting OpenVPN to work with
that future release (people will have to upgrade their os to get openvpn
support!) against having all new versions of OpenVPN work against all
existing versions of netbsd (assuming ofcourse this is the only issue in
getting openvpn work on netbsd). I don't have enough exposure to openvpn to
rightly make this judgement.

- Sanjay

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