Date: Wed, 28 Feb 2001 01:55:15 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: current@FreeBSD.ORG Subject: Re: [PATCH] for linux_connect (ugly) Message-ID: <20010228015515.A6763@crow.dom2ip.de> In-Reply-To: <Pine.BSF.4.21.0102272224580.12716-100000@levais.imp.ch>; from mb@imp.ch on Wed, Feb 28, 2001 at 01:17:12AM %2B0100 References: <3A6C7C25.A6101656@cup.hp.com> <Pine.BSF.4.21.0102272224580.12716-100000@levais.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 28, 2001 at 01:17:12AM +0100, Martin Blapp wrote: > Thomas Moestl and I tried to fix linux_connect. Most of this patch > is from Thomas Moestl. I did only a little part of it and testing. > > Staroffice5.2 has been broken about one year now, and it needs > a fix with the same behaviour to work correctly with FreeBSD. > > This patch should be rewritten so it can be comitted to CURRENT > and (IMPORTANT) to STABLE before 4.3 is out. > > + /* > + * Ugly kluge: some applications depend on 0 being > + * returned only the first time. Therefore, we set > + * the (otherwise invisible) SO_KNBCONN flag. > + * If it is set, return EISCONN. > + */ > + error = holdsock(p->p_fd, linux_args.s, &fp); > + if (error) > + return (error); > + iconn = ((struct socket *)fp->f_data)->so_options & > + SO_KNBCONN; > + ((struct socket *)fp->f_data)->so_options |= SO_KNBCONN; > + fdrop(fp, p); > + > + if (iconn) > + return (EISCONN); Some background: when a socket is connected in non-blocking mode and the connect does not immediately succeed (i.e. EINPROGRESS is returned), linux obviously will return the value getsockopt(...SO_ERROR...) on the socket would give on FreeBSD (i.e. 0 if the connection attempt succeeded) from the first connect() call on the socket after the connection has been established. Only the next call will returne EISCONN. So, the linuxulator has been modified in the past to always return the value getsockopt(...SO_ERROR...) gives. This does break applications that loop and wait for EISCONN, e.g. StarOffice. I might add that I do not particularly like this patch (because of fiddling with the socket internals) and consider it more of a quick fix. A somewhat cleaner solution might be to add a SO_USER socket option that can be freely set or reset by any FreeBSD application (without any effect). This could then be used to store connect state, and linux applications would run fine because they are ignorant of this. This way the getsockopt/setsockopt interface could be used in the linuxulator. Then again, maybe it is better to hide this... Well. I dislike the Linux behaviour. I see no really clean way of emulating this without touching our socket internals (a separate state could be kept in the linuxulator, but this is even more ugly, I presume). - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010228015515.A6763>