Date: Fri, 02 Oct 1998 23:48:24 -0700 From: Mike Smith <mike@smith.net.au> To: John Fieber <jfieber@indiana.edu> Cc: msmith@FreeBSD.ORG, nash@mcs.net, emulation@FreeBSD.ORG Subject: Re: Sybase update Message-ID: <199810030648.XAA01122@word.smith.net.au> In-Reply-To: Your message of "Fri, 02 Oct 1998 20:37:18 CDT." <Pine.BSF.4.02A.9810022017020.1057-100000@fallout.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Alex Nash and I have narrowed the problem with the Sybase server
> considerably. In fact, via an unacceptable hack it actually
> works.
Cool. Only a few steps away from a real solution then. 8)
> The problem is asynchronous i/o on a socket. As part of the
> initialization, the server sets up a socket for client
> connections which looks all okay and installs as SIGIO handler.
> Everything about the initialization look okay and compares well
> with a syscall trace generated on a Linux box...pretty much all
> differences can be explained.
Presumably it enables SIGIO delivery? It's masked by default...
> Here is a snippet of the syscall trace where the socket is setup
> (this is the linux one, much more readable than the FreeBSD one):
>
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
> setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> getpid() = 1191
> ioctl(5, SIOCSPGRP[, 1191]) = 0
> fcntl(5, F_SETOWN, 1191) = 0
> fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK|O_ASYNC) = 0
> bind(5, {sin_family=AF_INET, sin_port=htons(5000), sin_addr=inet_addr("192.168.129.58")}, 16) = 0
> listen(5, 128) = 0
>
> Two things I've had to change:
>
> * The SIGIO and SIGURG values in linux.h were reversed. I
> think they must have come from an incorrect man page (I found
> one on the net that had them wrong).
When you say "reversed", can you be more specific? The header I have
here gives SIGIO and SIGURG the same value (23).
> * F_SETFL didn't handel the O_ASYNC option. I added support
> to F_GETFL as well.
>
> Note that fixing the second without fixing the first resulted in a
> panic suggesting that somewhere in the kernel, there must be some
> action on the signals.
That's not too good. Did you get an idea as to where the panic was?
> At this point I'm getting a little over my head so any ideas of what
> to try next are most welcome. It would be super if 3.0 could
> ship "Sybase ready" which would grease the rails for lobbying
> Sybase to either loosen the License or give us a native version.
It sounds like you're extremely close. If you build the Linux LKM with
DEBUG defined, you should get a pile of "linux_sendsig" messages. You
can see the code that's meant to send the signal into the Linux process
in linux_sysvec.c:linux_sendsig(). Signal number translation is
handled elsewhere, but it uses the bsd_to_linux_signal table, and that
looks like it's correct as long as the value of LINUX_SIGIO is right.
> On the client side things are better. The only hangup is that if
> uname(2) returns a fully qualified internet name, the client library
> gets confused about the local host name and most applications just
> bail out at that point. I stuck a quick hack that truncates the
> hostname at the first period which makes it work, but that seems a
> little drastic.
Interesting. Does the Linux uname(2) call return a fully-qualified
hostname?
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810030648.XAA01122>