Re: [osol-discuss] How do I get maximum TCP buffer size without _PC_SOCK_MAXBUF on Solaris
I understand these and use them myself. _PC_SOCK_MAXBUF allows me to know reliably what the current maximum socket buffer size is. There are several uses with this little knowledge set the desire buffer size to the maximum without trial and error... channel efficiency analysis, etc... This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How do I get maximum TCP buffer size without _PC_SOCK_MAXBUF on Solaris
You are right about _PC_SOCK_MAXBUF is not being listed in unistd.h and is not listed as one of name's for fpathconf. However Single Unix Spec is pretty clear about its usage. Here are the quotes from SVSv3 (2004 edition)... The maximum value for the option for a socket may be obtained by the use of the fpathconf() function, using the value _PC_SOCK_MAXBUF. ... The SO_SNDBUF option requests that the buffer space allocated for send operations on this socket be set to the value, in bytes, of the option value. The default value for the SO_SNDBUF option value is implementation-defined, and may vary by protocol. The maximum value for the option for a socket may be obtained by the use of the fpathconf() function, using the value _PC_SOCK_MAXBUF. I'm going to send an inquiry to Open Groups' discussion group tonight (can't use personal mail account from work). This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] How do I get maximum TCP buffer size without _PC_SOCK_MAXBUF on Solaris 10?
Hi, I would like to obtain the maximum socket buffer size. Solaris seems to not support _PC_SOCK_MAXBUF for function fpathconf(). _PC_SOCK_MAXBUF is defined by POSIX. Regards, Shao. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: DTrace: How to print string in C++
two ways: 1. C++ way: #include iostream ... inside your function std::cout ret = a; 2. the good-old C way: printf(ret = %s, a.c_str()); This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Question about VMware and Solaris
If you don't need a support contract from RedHat, you can get Enterprise Linux for free by downloading the Community Enterprise Linux (a.k.a CENTOS) from here: http://www.centos.org/ Centos is build based on the same rhel without the commercial brand. It's fully binary, source, and rpm compatible with the rhel releases. In fact, you can download centos rpms to upgrade your rhel or download the rhel source rpms to upgrade/update your centos installation. centos is free without support (community support, that is...) and without the rh branding. You can also use VMWARE Server (free, but not open source) and/or Vmware Player (which is also free). This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Translated Solaris documentation in Chinese
Wow, the book is very cheap in China 49 Yuan (about US$6.28). It's an excellent site for technical books for people who can read Chinese. You can join them as a member for discounts, and free delivery for 21 universities Oh, wait, 21 universities in China, that's. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: are there any hardware instructions for byte swaps in sparc?
A gentlemen from Sun sent me an email and pointed out the samething with the actual implementation (md5). And that is exactly what I want to do with accessing the data. The email was sent to my yahoo.com account which I cann't access from work... One issue though, if the instruction for loading little-endian data requires memory addresses to be aligned, that could be be a problem because data are stored in compressed form without proper address alignment. I suppose I will have to resort to byte shifting ... Thanks, shao This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: are there any hardware instructions for byte swaps in sparc?
Interesting... but how does it work for generic application data? the way my application work is to encode the file to indicate data are stored in little-endian or big-endian format. The program accessing the data will do endian convertion if necessary (there is a data dictionary encoding the real type), or simply mmap if they both have the same byte-ordering. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: are there any hardware instructions for byte swaps in sparc?
cool thanks. Intel x86 (and AMD) processors have hardware instructions to perform byteswap and you can easily put an inline assembly instruction to do just that. The next best solution is to do byte shifting and or'ing bytes/bits to do endian conversions. Because the volume of data, anything that is faster than shifting/or'ing would improve the program performance significantly. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] are there any hardware instructions for byte swaps in sparc?
I wonder are there any hardware instructions to perform byte swaps (endian conversions) in SPARC? For example, if I open a data file that is stored in little-endian format, I would like to be able to read and convert the data as efficiently as possible. It would be very nice if I can mmap the data regions (as it were in big endian) and monkey with the data natives but that is too much to ask Thanks, Shao. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [osol-code] Will SunPCI II drivers be available in source form?
Sounds like a good idea. May be some of us will make it work with Linux or Solaris x86 and that will be an excellent thing for software testing one physical box, multiple physical machines sounds like a dream to me. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: [approach-discuss] Re: ioctl SIOCGENADDR returns ENOENT
I was referring to SIOCGIFHWADDR or SIOCGENADDR ioctl should work for non-root users, too... well, assuming it gets implemented. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: [approach-discuss] Re: ioctl SIOCGENADDR returns ENOENT
That is the tradition of ifconfig. arp gives you MAC addresses without being root. Programmatically, you can retrieve MAC by poking the ARP. It's a bit ugly since you have to know the IP of the nic to do that and it works for UP interfaces only. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Is 'forking' inevitable here too?
I think having different distrobutions of OpenSolaris is not a bad thing as long as each distro agrees on some basic frameworks: binary compatibilities with each other, common libraries, common kernel, common X window, common GNOME... At the user level, it shouldn't matter if someone makes a Linux-like Solaris, BSD-like Solaris, or Windows-like (with WINE??) Solaris. Since we are talking about Open, I can see that everyone starts with replacing close-source stuff with open source stuff. and that is perfectly reasonable to me. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Is 'forking' inevitable here too?
May be he meant BSD stem from System 5. SVR4 was a result of combining System 5, BSD (SunOS 4), and some of its new develoopments On the other hand, there is only one truly successful Unix derived from SVR4, and it's Solaris. All other Unix derived from SVR4 are either RIP or in their sunset days Linux will replace them in a few years. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Is 'forking' inevitable here too?
Clearly? If you discount the inventions done for SunOS at Sun, I don't think there's that much to show: sockets, reliable signal handling, r* commands. I thought sockets and reliable signals were originated from Berkley. Sun invented NFS, and the biggest take from SunOS were the virtual memory, virtual file system stuff (VOP_* stuff), and NFS. ATT (USL) were pushing their own streams interface instead of the BSD socket API. I think it's safer to say that there's common ancestry and that the torch of development passed from ATT to BSD to Sun (and that's where it still is, if you ask me :-) What about SCO? They invented Unix. Opsss This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: ioctl SIOCGENADDR returns ENOENT
This ioctl function did not work with Solaris 8 either. I fish out the mac address from ARP for now. Although I have strong preference on using standard interfaces (i.e. system calls), but I like your solution #1 better. Thanks. BTW, in the code, a file descriptor leaks whenever you retrieve the MAC successfully -- the fd should be closed before a successful return. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] ioctl SIOCGENADDR returns ENOENT
I would like to retrieve the MAC address for a given NIC by using the
SIOCGENADDR ioctl, but keep getting errno 2 (ENOENT). Do I miss something or
this ioctl is broken? My next question is, how can I retrieve the MAC address
of different kinds of NIC cards?
Thanks,
Shao.
Here is the code fragment I use:
#ifdef SIOCGENADDR /* Solaris: ethernet MAC addr */
if (ioctl(sockfd, SIOCGENADDR, ifr) == 0) {
memcpy(nic-m_haddr, ifr.ifr_enaddr, 6);
nic-m_hlen = 6;
}
#endif /* SIOCGNADDR */
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
