Re: emulation/43bsd patch

[qhwt@xxxxxxxxxxxxx]

On Wed, Sep 10, 2003 at 12:45:46PM +0000, David P. Reese Jr. wrote:
> In article <slrnbltq6n.q9f.daver@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, David P. Reese Jr. wrote:
> > In article <20030910082018.GA27649@xxxxxxxxxxxxx>, qhwt@xxxxxxxxxxxxx wrote:
> >> Hello.
> >> 
> >> On Wed, Sep 10, 2003 at 01:33:12AM +0000, David P. Reese Jr. wrote:
> >>> This patch creates an emulation/43bsd directory and moves the recently
> >>> modified compatibility syscalls there.  Any future work on the COMPAT_43
> >>> code should be split from the rest of the kernel and moved here.
> >>> 
> >>> http://gomerbud.com/daver/patches/dragonfly/emulation-43bsd.diff
> >>> 
> >>> If this patch gets positive feedback, I will commit the changes.
> >> 
> >> include/protocols/talkd.h still uses osockaddr and it bombs out
> >> building libexec/talkd during buildworld.
> > 
> > I'll post a new revision that fixes world issues tomorrow.
> 
> I've put some thought into this.  The only place in the source tree
> outside of src/sys that touches osockaddr is include/protocols/talkd.h.
> I can see no compelling reason for a userland app to be compiled with
> any of these compatibility structures.
> 
> If we wanted to, we could have installincludes install the 4.3BSD compat
> headers so that userland aps can be built from them.  The other option
> is to define osockaddr in talkd.h and keep the 4.3BSD compat headers
> private to the kernel.
> 
> The quick hack to talkd.h makes me cringe a bit less than exporting the
> headers.

Google told me that some other platforms define osockaddr or omsghdr
only if _SOCKADDR_LEN is defined prior to inclusion of socket.h .

IMHO, breaking compilation of (userland) applications that depend on
4.3BSD headers will not prevent users from running already compiled
versions of such applications on a system not supporting COMPAT_43 things,
so these struct's had better stay (conditionally) defined.
Just a bikeshed, though.