Once I stop laughing uncontrollably, I may be able to relate better. Friday night, one looser at work, me, working on some driver interfacing tool. And *bzzzzzz* *bzzzz* my cell phone rings. So its Mo, my dear old friend. He has a question about some software. So after telling him off for not being able to solve such a simple problem I guide him to the solution. And add in, you can also search the web for "PEBKAC" that would give you more information on the problem you are facing.
Mind you this conversation isn't on your standard crisp regular phone lines. This is on my Telus provider phone. Not too clear.
me: So you can also search Google for "P E B K A C"
Mo: Search for what?
me: P as in Pat, E as in Edison, B as in Bob, K as in Kangaroo, A as in Anim..
Mo: Hold on, P as in Pat, A as in Edison, B as in.. (mind you he does pronounce it "Edison")
me: Mo "E" as in Edison..
Mo: There is no Edison with "E"
Me: Thomas Edison?
Mo: Oh yeaaaa... its friday night.. i just want to sleep... okay so P as in Pat, E as in Edison, B as in Bob, K as in Kangaroo, A as in Awioejkja (he said something on the choppy line)
me: A as in What??
Mo: you know that species of monkeys, rare, extinct
Me: Mo.... its a BAD line, the point of this A as in .... is to make sense... how about something simple? like A as in Apple???
okay doesnt sound as funny now. But man both of us laughed our brains out.. on the A as in Aasdljf and A as in Edison.
BTW you should check out "PEBKAC", if you already don't know it. I usually don't like to refer to wikipedia, personally i feel its not too reliable. Well I guess it is for standard general knowledge, but go a bit technical, then it starts becoming "doubtable".
Friday, January 19, 2007
Friday, January 12, 2007
its magic... strace
Yes, so a follow up on my yesterday's post. I mentioned how I went thought ethereal's source code to figure out what IOCTLS to use. So I was talking to my co-worker about how toget that information and he told me to:
strace -e ioctl ifconfig
Now, I always liked strace and thought it was cool. But I feel mighty stupid how i didn't think of putting the two tools together. So yea, that spits out all the ioctl calls made by the tool. I found the Solaris equivalent truss.
strace -e ioctl ifconfig
Now, I always liked strace and thought it was cool. But I feel mighty stupid how i didn't think of putting the two tools together. So yea, that spits out all the ioctl calls made by the tool. I found the Solaris equivalent truss.
Wednesday, January 10, 2007
interface list from OS
Ignorant as I am, I, for my life, could not determine how to get the interface list and their mask, address, MTU, etc from the operating system (from a C program).
So the first thought was obvious, to use PCAP. So I did. using pcap_findalldevs, combined with pcap_lookupnet would yield me all the interface names and the network portion of the local iIP address and broadcast address. Of course I spent good amount of time to figure that out.
So I went back to google code search to find an alternative. And I saw libnet. Seemd way too much work than what I wanted to do. And using system("ifconfig -a | grep *!)$!:!@"); was really not an option.
Finally I decided, enough was enough. And I downloaded ethereal source code. I wassure I have seen interface name, address, mac address etc on ethereal. So a little grepping "grep interface *" gave me the result I was looking for, it pointed to me that it was possible to get this info from the system from an IOCTL. DUH! I didn't know that. :(
So web search on "struct ifreq" got me to this little gem . Ofcrouse, from there on it wasnt that difficult to figure it all out. Even I could do that. Oh and considering how I always get stuck at displaying the sockaddr_in from the ifreq in human format, I found this nice package that showed me how to do it.
And finally, I attach the source that I managed to write using the techniques from the web.
cheers!
So the first thought was obvious, to use PCAP. So I did. using pcap_findalldevs, combined with pcap_lookupnet would yield me all the interface names and the network portion of the local iIP address and broadcast address. Of course I spent good amount of time to figure that out.
So I went back to google code search to find an alternative. And I saw libnet. Seemd way too much work than what I wanted to do. And using system("ifconfig -a | grep *!)$!:!@"); was really not an option.
Finally I decided, enough was enough. And I downloaded ethereal source code. I wassure I have seen interface name, address, mac address etc on ethereal. So a little grepping "grep interface *" gave me the result I was looking for, it pointed to me that it was possible to get this info from the system from an IOCTL. DUH! I didn't know that. :(
So web search on "struct ifreq" got me to this little gem . Ofcrouse, from there on it wasnt that difficult to figure it all out. Even I could do that. Oh and considering how I always get stuck at displaying the sockaddr_in from the ifreq in human format, I found this nice package that showed me how to do it.
printf( "addr [%s]\n",
inet_ntoa( ( (struct sockaddr_in *) &ifr->ifr_addr )->sin_addr );
And finally, I attach the source that I managed to write using the techniques from the web.
cheers!
Thursday, January 04, 2007
compiler flags
I've been searching for some list of all compiler flags for various architectures and operating systems. Its very frustrating to get stuck at that. Considering my little knowledge, it takes me quite a fair bit of time to find what I need.
Thanks to Brian Hook, who seems to have collected a great list compiler defines for various architectures and operating systems. Here is the actual link.
GNU GCC/G++:
- __GNUC__: GNU C version
- __GNUG__: GNU C++ compiler
- __sun__ : on Sun platforms
- __svr4__: on Solaris and other SysV R4 platforms
- __mips__: on MIPS processor platforms
- __sparc_v9__: on Sparc 64-bit CPUs
- __sparcv9: 64-bit Solaris
- __MIPSEL__: mips processor, compiled for little endian
- __MIPSEB__: mips processor, compiled for big endian
- _R5900: MIPS/Sony/Toshiba R5900 (PS2)
- mc68000: 68K
- m68000: 68K
- m68k: 68K
- __palmos__: PalmOS
Intel C/C++ Compiler:
- __ECC : compiler version, IA64 only
- __EDG__
- __ELF__
- __GXX_ABI_VERSION
- __i386 : IA-32 only
- __i386__ : IA-32 only
- i386 : IA-32 only
- __ia64 : IA-64 only
- __ia64__ : IA-64 only
- ia64 : IA-64 only
- __ICC : IA-32 only
- __INTEL_COMPILER : IA-32 or IA-64, newer versions only
Apple's C/C++ Compiler for OS X:
- __APPLE_CC__
- __APPLE__
- __BIG_ENDIAN__
- __APPLE__
- __ppc__
- __MACH__
DJGPP:
- __MSDOS__
- __unix__
- __unix
- __GNUC__
- __GO32
- DJGPP
- __i386, __i386, i386
Cray's C compiler:
- _ADDR64: if 64-bit pointers
- _UNICOS:
- __unix:
SGI's CC compiler predefines the following (and more) with -ansi:
- __sgi
- __unix
- __host_mips
- _SYSTYPE_SVR4
- __mips
- _MIPSEB
- anyone know if there is a predefined symbol for the compiler?!
MinGW:
- as GnuC but also defines _WIN32, __WIN32, WIN32, _X86_, __i386, __i386__, and several others
- __MINGW32__
Cygwin:
- as Gnu C, but also
- __unix__
- __CYGWIN32__
Microsoft Visual Studio predefines the following:
- _MSC_VER
- _WIN32: on Win32
- _M_IX6 (on x86 systems)
- _M_X64: on x86-64 systems
- _M_ALPHA (on DEC AXP systems)
- _SH3: WinCE, Hitachi SH-3
- _MIPS: WinCE, MIPS
- _ARM: WinCE, ARM
Sun's C Compiler:
- sun and _sun
- unix and _unix
- sparc and _sparc (SPARC systems only)
- i386 and _i386 (x86 systems only)
- __SVR4 (Solaris only)
- __sparcv9: 64-bit solaris
- __SUNPRO_C
- _LP64: defined in 64-bit LP64 mode, but only if is included
Borland C/C++ predefines the following:
- __BORLANDC__:
DEC/Compaq C/C++ on Alpha:
- __alpha
- __arch64__
- __unix__ (on Tru64 Unix)
- __osf__
- __DECC
- __DECCXX (C++ compilation)
- __DECC_VER
- __DECCXX_VER
IBM's AIX compiler:
- __64BIT__ if 64-bit mode
- _AIX
- __IBMC__: C compiler version
- __IBMCPP__: C++ compiler version
- _LONG_LONG: compiler allows long long
Watcom:
- __WATCOMC__
- __DOS__ : if targeting DOS
- __386__ : if 32-bit support
- __WIN32__ : if targetin 32-bit Windows
HP-UX C/C++ Compiler:
- __hpux
- __unix
- __hppa (on PA-RISC)
- __LP64__: if compiled in 64-bit mode
Metrowerks:
- __MWERKS__
- __powerpc__
- _powerc
- __MC68K__
- macintosh when compiling for MacOS
- __INTEL__ for x86 targets
- __POWERPC__
Thanks to Brian Hook, who seems to have collected a great list compiler defines for various architectures and operating systems. Here is the actual link.
GNU GCC/G++:
- __GNUC__: GNU C version
- __GNUG__: GNU C++ compiler
- __sun__ : on Sun platforms
- __svr4__: on Solaris and other SysV R4 platforms
- __mips__: on MIPS processor platforms
- __sparc_v9__: on Sparc 64-bit CPUs
- __sparcv9: 64-bit Solaris
- __MIPSEL__: mips processor, compiled for little endian
- __MIPSEB__: mips processor, compiled for big endian
- _R5900: MIPS/Sony/Toshiba R5900 (PS2)
- mc68000: 68K
- m68000: 68K
- m68k: 68K
- __palmos__: PalmOS
Intel C/C++ Compiler:
- __ECC : compiler version, IA64 only
- __EDG__
- __ELF__
- __GXX_ABI_VERSION
- __i386 : IA-32 only
- __i386__ : IA-32 only
- i386 : IA-32 only
- __ia64 : IA-64 only
- __ia64__ : IA-64 only
- ia64 : IA-64 only
- __ICC : IA-32 only
- __INTEL_COMPILER : IA-32 or IA-64, newer versions only
Apple's C/C++ Compiler for OS X:
- __APPLE_CC__
- __APPLE__
- __BIG_ENDIAN__
- __APPLE__
- __ppc__
- __MACH__
DJGPP:
- __MSDOS__
- __unix__
- __unix
- __GNUC__
- __GO32
- DJGPP
- __i386, __i386, i386
Cray's C compiler:
- _ADDR64: if 64-bit pointers
- _UNICOS:
- __unix:
SGI's CC compiler predefines the following (and more) with -ansi:
- __sgi
- __unix
- __host_mips
- _SYSTYPE_SVR4
- __mips
- _MIPSEB
- anyone know if there is a predefined symbol for the compiler?!
MinGW:
- as GnuC but also defines _WIN32, __WIN32, WIN32, _X86_, __i386, __i386__, and several others
- __MINGW32__
Cygwin:
- as Gnu C, but also
- __unix__
- __CYGWIN32__
Microsoft Visual Studio predefines the following:
- _MSC_VER
- _WIN32: on Win32
- _M_IX6 (on x86 systems)
- _M_X64: on x86-64 systems
- _M_ALPHA (on DEC AXP systems)
- _SH3: WinCE, Hitachi SH-3
- _MIPS: WinCE, MIPS
- _ARM: WinCE, ARM
Sun's C Compiler:
- sun and _sun
- unix and _unix
- sparc and _sparc (SPARC systems only)
- i386 and _i386 (x86 systems only)
- __SVR4 (Solaris only)
- __sparcv9: 64-bit solaris
- __SUNPRO_C
- _LP64: defined in 64-bit LP64 mode, but only if
Borland C/C++ predefines the following:
- __BORLANDC__:
DEC/Compaq C/C++ on Alpha:
- __alpha
- __arch64__
- __unix__ (on Tru64 Unix)
- __osf__
- __DECC
- __DECCXX (C++ compilation)
- __DECC_VER
- __DECCXX_VER
IBM's AIX compiler:
- __64BIT__ if 64-bit mode
- _AIX
- __IBMC__: C compiler version
- __IBMCPP__: C++ compiler version
- _LONG_LONG: compiler allows long long
Watcom:
- __WATCOMC__
- __DOS__ : if targeting DOS
- __386__ : if 32-bit support
- __WIN32__ : if targetin 32-bit Windows
HP-UX C/C++ Compiler:
- __hpux
- __unix
- __hppa (on PA-RISC)
- __LP64__: if compiled in 64-bit mode
Metrowerks:
- __MWERKS__
- __powerpc__
- _powerc
- __MC68K__
- macintosh when compiling for MacOS
- __INTEL__ for x86 targets
- __POWERPC__
Tuesday, January 02, 2007
solaris driver
So in desperate attempt to contribute in some way, constructive way, to our release, I decided to put all my effort into making the Solaris stub driver that would later on be filled with the required content. So my hard work paid off and I found this link. It basically walks you through all the steps of creating a dummy driver for Solaris.
So after understanding that code [read: copying & pasting] , I gave gcc a chance to prove its worth. But no, I would not assist gcc by giving away the compiler flags. After a bit more of search on the web, I realized, thats the way of life. I would have to give the right compiler flags which, thanks to ReneS, I plugged in. However sun has a good coverage for gcc and cc compiler over here. In short (from the sun site above):
------------------------------------------------------------------
Since I was Compiling for amd64 x86 Solaris 10, my options looked like
KERNEL_CFLAGS= -D_KERNEL -m64 -mcmodel=kernel -mno-red-zone -ffreestanding -nodefaultlibs -c mydriver.c
and lo and behold, it compiled.
so next step was to load pfil with it. And all that I understand of pfil is between the lines below.
-------------------------------
-------------------------------
So after understanding that code [read: copying & pasting] , I gave gcc a chance to prove its worth. But no, I would not assist gcc by giving away the compiler flags. After a bit more of search on the web, I realized, thats the way of life. I would have to give the right compiler flags which, thanks to ReneS, I plugged in. However sun has a good coverage for gcc and cc compiler over here. In short (from the sun site above):
------------------------------------------------------------------
Use the -D_KERNEL option to indicate that this code defines a kernel module. These examples show options that are required for correct functionality of the result.
-
If you are compiling for a 64-bit SPARC architecture, use the following build commands:
% gcc -D_KERNEL -m64 -mcpu=v9 -mcmodel=medlow -fno-pic -mno-fpu -ffreestanding -nodefaultlibs -c mydriver.c
% /usr/ccs/bin/ld -r -o mydriver mydriver.oYou might also want to use the -mtune=ultrasparc option and the -O2 option.
-
If you are compiling for a 64-bit x86 architecture, use the following build commands:
% gcc -D_KERNEL -m64 -mcmodel=kernel -mno-red-zone -ffreestanding -nodefaultlibs -c mydriver.c
% /usr/ccs/bin/ld -r -o mydriver mydriver.oYou might also want to use the -mtune=opteron option and the -O2 option.
-
If you are compiling for a 32-bit architecture, use the following build commands:
% gcc -D_KERNEL -ffreestanding -nodefaultlibs -c mydriver.c
% /usr/ccs/bin/ld -r -o mydriver mydriver.o
Since I was Compiling for amd64 x86 Solaris 10, my options looked like
KERNEL_CFLAGS= -D_KERNEL -m64 -mcmodel=kernel -mno-red-zone -ffreestanding -nodefaultlibs -c mydriver.c
and lo and behold, it compiled.
so next step was to load pfil with it. And all that I understand of pfil is between the lines below.
-------------------------------
-------------------------------
Subscribe to:
Posts (Atom)