pete@ecrcvax.UUCP (Pete Delaney) (06/13/85)
I'm installing the ISO transport class 4 being developed by the ESPIRIT ROSE project by lvbull!sylvain. When I ported the sockets, TCP/UDP/IP, etc, on our machine, a Level-6, it was easy to start with a larger sockaddr structure that would be large enough for both INET and ROSE/ISO sockaddr's. However, now that I'm installing it on the vax it's more of a hassle to extend the size of a sockaddr structure and keep the old stuff still working. It seem that the changes have to be done BOTH for COMMANDS and the KERNEL at the SAME TIME because the Berkeley compiler generates switches using long numbers. The Level-6 compiler uses integers. Thus, for example, invokeing the ifconfig command will result in an ioctl error since the ioctl cmd SIOCGIFFLAGS won't match because the size of the ifreq structure has changed! Last year when I was dealing with this switch on ioctl's I think the C reference manual implied that the code should have only used a short. Hmmm. I wonder what the C standard is, anyone know? It seems like the way Berkeley is doing it makes more sense. I thought before compiling the network commands it would be nice to know if their is reason to take another approach. I extended the size of the sockaddr structure from 16 bytes to 32 while at lvbull. I wonder now if we may have to make it larger for say one of the other ISO address families. The ISO/DP 8348/DAD2 specifies a 20 byte binary maximimum and a 40 byte 'decimal' max for the Network Service Access/Address Point (NSAP). Running higher layer protocols may require more address information. Any suggestions on the new size for a sockaddr structure? 32? 48? Sorry for the Flamming Pete -- -------------------------------------------- Pete Delaney - Rocky Mnt. Unix Consultant Phone: (49) 89 92699-139 European Computer-Industry Research Center UUCP: mcvax!unido!ecrcvax!pete ArabellaStrasse 17 UUCP Domain: pete@ecrcvax.UUCP D-8000 Muenchen 81, West Germany X25: (262)-45890040262 CSNET:pete%ecrcvax.UUCP@Germany.CSNET Login: <to be provided?> ------------------------------------------------------------------------------