emulate floppy in linux

So I was trying to write a "hello world" "OS" and then add more functionality to it.. just to try it out.

My colleague had showed me a nice link osdev.org. quite intersting resource regarding os development. There they had tutorials on how to get started.

I found this to be a very nice link to get me started:
http://www.osdever.net/downloads.php

One of the steps involved making a boot floppy with grub etc installed on it. Now I was using vmware and didnt hava floppy drive. So I knew I could use dd to create an image and then change the image's filesystem. Just didnt konw how exactly. So my co-worker gave this!

# create a image of Zeros of length 2048 bytes
dd if=/dev/zero of=floppy.img bs=1024 count=2048

#make the image of ext2 file system
mkfs.ext2 floppy.img

#create a mount point
mkdir floppy.d

#mount the image to the mount point
mount -o loop floppy.img floppy.d


Now you can treat the floppy.d directory as a floppy drive! and then unmount when done and transfer the image anywhere!



works like a charm :)

chroot after rsync

So I had a fedora core 6 box 64 bit that I needed to set up as a build box. t needed to build:

Redhat4 32 bit
Redhat4 64 bit
Redhat5 32 bit
Redhat5 64 bit

So now I had a few options to choose from,
- have 2 chroots' /redhat4 and /redhat5 and then chroot to redhat4 and build 32 and 64 bit drivers and repeat the process for /redhat5

OR
- have 4 chroots' and keep each build seperate. so I would have /redhat4_32 /redhat4_64 /redhat5_32 and /redhat5_64

Going the first route meant I would have to propagate the architecture all the way from top level build initiating script down to all the sub projects. The second option seemed better over the long run.


So the process is pretty simple. The over all steps are as follows:

systems:
gandalf - the box that needs to have whole build environment
boromir - temporary vmware image that will be deleted later. (as boromir does die!)

1- install redhat4 32 bit on boromir
2- create /redhat4_32 dir on gandalf
3- copy all the files from boromir to gandalf:/redhat4_32
4- set up the appropriate mounts for /proc and /dev
5- thats it.. chroot into /redhat4_32 on gandalf

Lord Macaulay, dated the 2nd February 1835

After receiving the email for the 2nd time I wanted to find out if it really was true. It was an email about Lord Macaulay praising India after this visit in 1833.

a quick Google search for:
Lord Macaulay Feb 2 1835

got me the desired results. got me the results I was looking for. It seems like an obvious fraud... well covered at google answers:
http://answers.google.com/answers/threadview?id=296771
and here:
http://koenraadelst.bharatvani.org/articles/hinduism/macaulay.html

Google Query:
http://www.google.com/search?q=Lord+Macaulay++Feb+2%2C+1835&btnG=Search&hl=en&safe=off

vmware to qemu convert

So we were developing drivers for solaris 10 at our company. Since we didnt have nough sparc machines, most of the dev happened on our vmware x86 solaris boxes. My co-worker (from whom I have learnt more aobut linux in the last 8 months than I learnt in the last few years on my own) showed me the way to convert the VMware image to qemu image. Without further ado, here is the command

qemu-img convert /mnt/1/Solaris10.x86.64/Sol_x86_64.vmdk -O qcow solaris-10-64bit.img

ubuntu and me!

okay, so I bit the bullet and tried something other than good ol' redhat this time. So I tried Ubuntu. one thing about it however I didnt like is all the fancy GUI. Considering I run a WinxP box with 2 VMWare images of some flavor of linux. One for mostly development and other for testing out the drivers.

So the fancy GUI of ubuntu was taxing my systems resources. I like my wmii very much. Convenient and light weight. wmii with ruby is apparently faster. I didn't get around experimenting with it much. Hmm I also liked ion however. Pretty convenient.

Alright so here are the packages I usually install:

vim (no way i am not installing that)
wmii (ditto)
php-apach-mysql (just for some playing around)
svn (need to access source)
screen (another one of those magical creations you can't live without)

thats about it I think. I will post my .rc files sometime. They way I go about them is something like this:

I have a ~/.env directory in which I place my .vimrc .bashrc .wmmirc etc rc files. And in the ~/ I add a link to them or just add a line like:

source ~/.env/vimrc

to pick up my rc files. So when I move to new PC I just need to copy the .env dir and go from there.

What my co-worker does, which I think is a good idea is that he has his git server with the above files maintained by the source control.

stdio.h: No such file or directory

So its me again... with a new installation of ubuntu this time. My co-worker kept saying a lot of good things about debian so I figured might as well try the closest thing to it that I was willing to give a shot.

So after installation and everything. I pulled down the source and tried to compile a simple c program and I got the weirdest of errors saying the system couldn't find stdio.h? Now that shows my experience with devlopment probably, but I hadn't seen that error before.

So a little search got me the solution. Its apparently the package build-essential that includes the required libraries.

sudo apt-get install build-essential

did the trick.

resources....

okay.. so remember the site I pointed out last time for the mount command? It has some prettty good links.
I have mirrored one of them as I found the page a bit hard to reach. Specially with the spaces in filename.

Well here is the list of all commands in Solaris.

mounts

okay... so we had a customer issue, where our kernel module would screw up while loading and would reboot the system. So this, as you can imagine, was a vicious cycle.

So not knowing and easier ways, and not having a boot disk handy, I had to do something to get it past the drivers. These were kernel modules binding to the network drivers that were being messed up. So normally you'd think that unplugging the network cable would cause the bge0 to fail and thus the there would be no network driver to bind to. Hence our modules would not load. But no, the interface was in static address, so it didnt matter if the cable was plugged in.

We were thrown into recovery mode where the OS was mounted ReadOnly, and i couldnt figure out how to make it read write.
Finally, searching the web gave me a this good resource that helped out.

Solution?

mount -F ufs -o rw,remount /

worked like a charm, and saved us good 30 mins of other methods.

A as in Edision

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".

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.

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.

 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!

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__

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):

------------------------------------------------------------------

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.o

  You 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.o

  You 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.
-------------------------------





-------------------------------