I'm trying to port hercules (IBM mainframe emulator) to Solaris; hit the following snags so far:
* FP_INFINITE FP_NAN FP_NORMAL FP_SUBNORMAL FP_ZERO don't seem to be defined anywhere in /usr/include. http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html seems to indicate that as of whatever version of SUS, ISO/IEC 9945-[12], IEE 1003.[12], etc. it represents, those should be available when including <math.h>. So I'd like to think that eventually, Solaris would have these. (Hopefully temporary) workaround: add to the source file that uses them #if defined(__SVR4) && defined(__sun) /* i.e. Solaris */ #ifndef FP_INFINITE /* don't define them if they're already there */ #define FP_INFINITE 1 #define FP_NAN 2 #define FP_NORMAL 3 #define FP_SUBNORMAL 4 #define FP_ZERO 5 #endif #endif (since the hercules code doesn't seem to care about specific values or obtain them from other than its own code, but only cares that they have distinct values) * next problem: the code to emulate Direct Access Storage Devices (DASD, i.e. typically disk) includes a call to the Linux BLKGETSIZE ioctl, which returns the size of a disk-like storage device in 512 byte blocks. To make life more interesting, they're using it on a block device; Solaris doesn't allow ioctls on block devices, although it looks to me as if it could be trivially changed to do so by changing if (vp->v_type != VCHR) in spec_ioctl() (file specvnops.c) to if (vp->v_type != VCHR && vp->v_type != VBLK) since Solaris consolidates the traditional bdevsw and cdevsw entry points into a single cb_ops structure. I don't know what if anything else that might break; the mere notion of allowing ioctls on block devices isn't particularly traditional, but neither is it all that shocking; not only Linux, but some more mainstream examples of the AT&T lineage have allowed that: ISTR PC/IX for the PC/XT, based on SysIII, allowed it; doubtless other more recent examples also exist. Since one can't actually obtain a file descriptor to the pseudo-block-device that may exist corresponding to something like an NFS mount (which clearly couldn't handle an ioctl), I don't see that that case should ever arise, so I'm hard-pressed to see what harm there would be in allowing ioctls on block devices, and eliminating the need to map from a block to an equivalent character device might make life simpler in some other code, too. But all that would do is keep me from having to locate the character device corresponding to the block device; a nontrivial exercise (if one excludes simply editing the pathname to put an "r" in the appropriate place, which isn't perhaps so trivial if one throws in not only /dev/dsk, but /dev/md/dsk, /dev/vx/dsk, whatever /vol is up to, and any other variants) that I'd like some suggestions on, but I'd still have to use perhaps a dkio(7i) ioctl to fetch the partition size and somehow determine (not by the device name, please!) which partition I was looking at. Hints as to what the best equivalent to BLKGETSIZE might be would definitely be appreciated. * No doubt another problem will be tape-handling code. I could perhaps just #ifdef out the handling of real tape devices, since I'll probably be using only emulated tape devices anyway, but I'd welcome any examples of Linux-to-Solaris ports, in case I care to take a shot at it, since I don't have anything to test on (well, nothing fast enough or not on its last legs...no SCSI card in my Sun Blade 100, and my SPARC 10's system boot disk bit the dust awhile back, and a Voyager running diskless would be plain silly to try to run hercules on, even if my old 8mm tape drive still works). * No idea yet what other problems I'll hit; got to get past the BLKGETSIZE equivalent first (don't want to #ifdef use of real block devices out just to keep moving) All this is 'cause I've been playing around with hercules in Windows on my new laptop (which also has Solaris on it, of course). I could perhaps load Linux on it too (have space set aside, in case I find a distro that wouldn't take too much tinkering to work decently on there), but that's another problem; I think it could be 'way cool to have hercules running on a Sun, regardless. If IBM would license some of their more modern OSs (20-year old MVS 3.8j is a bit long in the tooth), it might be more than just cool, esp. on a system with multiple UltraSPARC or AMD64 processors. :-) Ok, not likely to happen, but fun to imagine, anyway... On an unrelated topic, I don't know if it's true in the very latest version of Veritas vxvm, but I noticed that they didn't support using a /dev/vx/dsk/... device as a dump device (although one can with SDS metadevices); turns out they didn't implement the entry point for dump device support (although they had the cb_print entry point that Nobody _Ever_ Uses!). Someone ought to beat them up a bit over that... This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
