Many versions of Linux have been ported to the Macintosh, but were not initially developed for the Mac. Ubuntu falls into this category. There are some PC features that do not exist on the Mac, and some Mac features that lack support under Ubuntu.

Using a One-Button Mouse in a Three-Button World

The biggest issue with using Ubuntu on a Mac is the lack of a three-button mouse. Under Ubuntu, the left mouse button performs actions, such as selecting icons and moving windows. The right button brings up menus, and the middle button is used for pasting from the clipboard.

Tip: There are many different types of PC mice. Some only have two-buttons. The middle button can be emulated by clicking both the right and left buttons at the same time. Others have a scroll wheel that can be pushed in for use as the third button.

Most Macs include a one-button mouse. If you swap the one-button mouse for a three-button model, it will work fine with Ubuntu, but if you do not want to swap hardware then how do you use the other buttons?

By default, Ubuntu on the Mac (PowerPC platform) maps the F11 and F12 keys to the middle and right mouse buttons. This is configured in the /etc/sysctl.conf file. On the PowerPC installation, this file contains the following additional lines:

# Emulate the middle mouse button with F11 and the right with F12.

dev/mac_hid/mouse_button_emulation = 1

dev/mac_hid/mouse_button2_keycode = 87

dev/mac_hid/mouse_button3_keycode = 88

On a Mac, keycode 87 is F11 and keycode 88 is F12. One easy way to see the keycodes is to use the X Event Tester (xev ). This tool opens a window and displays all X-Windows events. If you type in the window, it displays the keycodes.

The xev application, showing keycodes

Missing Keys and Functionality

PC keyboards usually do not look like Mac keyboards. The standard 104-key PC keyboard contains many extra keys that are not found on a Mac. Some of the missing keys include:

• Two Alt keys -Every Mac keyboard has a left Alt key (Alt_L), but the right Alt key (Alt_R) is not always present.
• Two Ctrl keys -While Control_L always exists, Control_R may be missing on some Mac keyboards.
• System keys -The Print Screen, System Request, Scroll Lock, Pause, and Break keys are missing. With Ubuntu on a PC, the Print Screen button is mapped to the screen capture application. Without this button, you will need to remap the functionality to another key combination.
• Edit keys -Most PC keyboards have a set of keys for Insert, Delete, Home, End, Page Up, and Page Down. Although Mac keyboards do have Page Up and Page Down, they are not in the same location as a PC keyboard. Different Mac keyboards can have very different keys. For example, the Mac iBook G4 has Home/End while the older iMac G3 keyboard has Home and Help (where Help generates the same keycode as Insert).
• Windows keys -The Windows keys do not exist on the Mac keyboard (for obvious reasons). Similarly, the Menu key does not exist.
• Numeric keyboard -Although they are usually not labeled on the Mac, the numeric keyboard does have the same arrows (KP_Up, KP_Down, KP_Left, and KP_Right) and navigation keys as a standard PC keyboard.

Keys Please

Under X-Windows, there are two types of keyboard values: keycodes and keysyms. Keycodes are the actual numeric representation sent by the keyboard when a key or button is pressed. Keysyms are the values assigned to the keycodes. For example, when you press the A key on the keyboard, it generates keycode 73. Keycode 73 is mapped to the keyboard symbol 0×61 (the letter a). The command xmodmap -pk prints the key table, showing the keycode to keysym mapping. For example, here’s a section of output from the key table:

55 0xff6a (Help) 0xff6a (Help)

56 0×0030 (0) 0×0029 (parenright)

57 0×0031 (1) 0×0021 (exclam)

58 0×0032 (2) 0×0040 (at)

59 0×0033 (3) 0×0023 (numbersign)

This key table shows that keycode 56 is mapped to the number zero, and when shifted, maps to a right parenthesis.

It is important to realize that not every keyboard can generate every keycode, and not every keycode is mapped to a keysym. Other input devices also generate key- codes. For example, the mouse buttons are keycodes 1, 2, and 3 (for left, middle, and right). Using xmodmap , you can change the key table, swapping keyboard keys or mouse buttons. For example, the command xmodmap -e “pointer = 3 2 1″ flips the mouse buttons for a left-handed mouse.

There are also some keys that exist on the Mac but not on the PC. By default, these are not mapped to anything but can be mapped to other keys.

• Command keys -On a Macintosh keyboard, there is at least one and possibly two Command keys. These are located on either side of the spacebar and are labeled with a flower pattern. Mac users call this the Apple or Command key. Under Linux, it is called the Super key. The left one (Super_L) is mapped to keycode 115 and the right key (Super_R) is keycode 116.
• Keypad Equal (=) -On a standard PC keyboard, there is no equal sign on the numeric keypad, but there is one on the Mac. This key is mapped to keycode 157 but is not mapped to any keyboard value.

Changing Keyboard Layouts

By default, Ubuntu configures itself for a generic 104 key PC keyboard. This is not the same layout as a Macintosh. You can change the configuration to match your keyboard by choosing System -> Preferences -> Keyboard. This brings up the keyboard configuration applet. From here, you can change the keyboard model to match your Mac keyboard . Changing the keyboard layout changes the keycode to keysym map.

The Keyboard Preferences applet for changing keyboard models.

Remapping the Command and Alt Keys

One of the biggest distinctions for Mac users is the use of the Command key. Under Mac OS, this key modifier is used for most shortcuts. For example, Command+W closes the window and Command+Q quits an application. Under Ubuntu and on most PC operating systems, the Ctrl key has the same usage (for example, Ctrl+W instead of Command+W). Adding to the confusion, a PC keyboard has Alt next to the spacebar whereas a Mac has the Command keys in that location. What this means is that a Mac user running Ubuntu will need to relearn how to use the Alt key instead of the Command key, or you can just remap the keys.

To remap the Command keys to act as Alt keys, use the xmodmap program. This program maintains a list of keycode mappings (xmodmap -pke ) and special key modifiers such as Shift and Control (xmodmap -pm ). The easiest way to remap the Command keys is to simply change the modifiers. First, remove the control and command keys, then add the Ctrl keys again.

xmodmap -e “remove control = Control_L Control_R” # unmap control

xmodmap -e “remove mod4 = Super_L Super_R” # unmap old Super keys

xmodmap -e “add control = Super_L Super_R” # map Super to Ctrl

Alternately, you could actually re-map the Command and Ctrl keys.

xmodmap -e “remove control = Control_L Control_R” # unmap Ctrl

xmodmap -e “remove mod4 = Super_L Super_R” # unmap super

xmodmap -e “keycode 115 = Control_L Control_L” # map Command to Alt

xmodmap -e “keycode 116 = Control_R Control_R” # map Command to Alt

xmodmap -e “keycode 64 = Super_L Super_L” # map Alt to Command

xmodmap -e “keycode 113 = Super_R Super_R” # map Alt to Command

xmodmap -e “add control = Control_L Control_R” # map new Ctrl to Ctrl

Mapping the keyboard using xmodmap only creates a temporary change. If you reboot the computer or restart the X-server, the changes will be lost. To make the changes permanent, you can put the changes in ˜/.Xmodmap or /usr/X11/xinit/Xmodmap -depending on whether you want the changes to be per user or system wide:

remove control = Control_L Control_R

keycode 115 = Super_L Super_L

keycode 116 = Super_R Super_R

remove mod4 = Super_L

add control = Super_L Super_R

Tip: After creating .xmodmap, you can test it using the command xmodmap .xmodmap. Be sure to correct any errors, otherwise the configuration will not load.

Note: Under the default Dapper installation, Super_R is not defined, so you will need to map it to key- code 116 before using it. Also, Super_L is part of the mod4 modifiers. Use xmodmap -pm to display the modifier list.

Instead of adding the mappings to the .xmodmap file, you can add the xmodmap commands to ˜/.xinitrc or /etc/X11/xinit/xinirrc . You might want to do this anyway since Gnome will prompt you about using a new .xmodmap file each time you log in.

Shas’t Nos Funny!

There’s an old practical joke where people pry the keys off a keyboard and replace them out of order. A user who is not a touch typist can get really confused when they look for the right letters. The xmodmap command can be used for an excellent alternative to this prank. For example, you can add the following commands into the victim’s .bashrc file:

xmodmap -e ’keycode 91 = t T’

xmodmap -e ’keycode 92 = s S’

This prank swaps the s and t keys on the keyboard without requiring any physical keyboard modifications. Alternately, if you can pry up and replace the keys on the keyboard, follow it up by remapping the keyboard so it actually works correctly! Your coworkers should get a big laugh out of it!

“Everything is a file in Linux� is an oft repeated statement. What this basically implies is that all the devices (Hard disks,CD ROMs, Floppy Disks, USB Sticks,etc) are all treated as files.

Just to explain this a bit more ,let us consider the C function write(f,&buf,len) . You must have used this function to write len bytes of data contained in buf to a file whose File Descriptor is given by f. Linux allows you to use the same function to write to a floppy (in the simplest of cases) as well. This is because everything capable of input and output is treated as a file in Linux. This is one of the two major abstractions in Linux, the other being a Process.

A filesystem is the methods and data structures that an operating system uses to keep track of files on a disk or partition; that is, the way the files are organized on the disk. The word is also used to refer to a partition or disk that is used to store the files or the type of the filesystem. Thus, one might say I have two filesystems meaning one has two partitions on which one stores files, or that one is using the extended filesystem, meaning the type of the filesystem.

Linux Filesystems

One of the most important features of Linux is its support for many different file systems. This makes it very flexible and well able to coexist with many other operating systems. ext2fs, ext3fs, ReiserFS, vfat, minix are among the major supported file systems. You can have have multiple filesystems on each partition of your hard disk and make them co-ordinate beautifully. For example you could install the Linux system in your ext3 partition and store all your data in a vfat partition.

Now to support the multiple filesystems relevant support should be built into the Linux kernel to recognize them. This again implies that the we must be having different mechanisms to write to a hard disk file and to a floppy disk file as they are having different filesystems. However we just mentioned in the beginning that we can use the same function to achieve the objective. Does this mean that we are having different implementations of the function for each filesystem? Fortunately, No. This would otherwise make the kernel bigger and decrease the extensibility of the kernel to support newer file systems. There is only a single implementation of the function and hence the same function may be used to write data to files stored on different filesystems. This is possible by the use of The Vitual Filesystem.

The Virtual Filesystem

The Virtual Filesystem henceforth referred to as VFS, is the subsytem of the Linux kernel which implementats the filesystem related interfaces provided to user space programs. The interoperability of the filesystems is made possible by the VFS.

Figure 1
As is apparent from the figure (Figure 1) , the requests from the user space application layer programs are received by the VFS which then interacts with the low level filesystems such as ext2,ext3,etc. Thus the VFS provides a layer of abstraction around the low-level filesystem interface. This is possible because the VFS provides a common file model that is capable of representing any conceivable filesystem’s general features and behavior.

Implementation of the VFS

The VFS is object-oriented. Well this might actually surprise you as it did me. The Linux kernel is programmed in C, so how come the VFS is object-oriented? This does not mean the VFS is coded using classes , objects and other OOPS features. VFS is object oriented in the sense that the whole implementation is built around the concept of objects. Since C does not support OOPS constructs such as classes therefore the data structures which are used to implemented object oriented C code are represented as C structures.
The four primary object types of the VFS are:

• The superblock object which represents a specific mounted filesystem
• The inode object which represents a specific file
• The dentry object which represents a directory entry, a single component of a path
• The file object which represents an open file as associated with a process

An operations object is contained within each of this primary objects and they define the operations that the kernel invokes on each of these objects. Specifically these are:

• The super_operations object is a structure which is used by the kernel to read and write inodes, write superblock information back to disk and collect file system statistics as required by the system calls like fstatfs and statfs
• The inode_operations object contains methods which the kernel can invoke on a specific file such as create( ) and link( )
• The dentry_operations object contains the methods that the kernel can invoke on a specific directory entry, such as d_compare( ) and d_delete( )
• The file object contains the operations that a process can invoke an open file such as read( ) and write( )

The Superblock Object and Superblock Operations

The superblock object represents a specific mounted file system. It usually corresponds to the file system superblock or file system control block on disk. A superblock is created and initialized when filesystem is mounted.

The superblock object is represented by struct super_block and defined in

As you can see above, there is a field struct super_operations s_op. This field defines a interface to the struct super_operations defined in < linux / fs.h >. This structure represents the superblock operations table. Listing 2 reproduces the important fields of the table:

Listing 2
——————————————–CODE—————————————-
struct super_block{
…..
struct inode *(*alloc_inode)(struct super_block sb); /* Create and initialize a new inode object */
void (*read_inode) (struct inode inode); /* Read a inode from disk */
void (*dirty_inode) (struct inode inode); /*Invoked by the VFS when the inode is dirtied / modified*/
void (*write_inode) (struct inode inode, int wait); /* write the given inode to disk */
int (*sync_fs) (struct super_block sb, int wait); /* Synchronizes filesystem metadata with ondisk meta data */
int (*statfs) (struct super_block sb, struct statfs statfs); /* statfs( ) system call */
int (*remount_fs) (struct super_block sb, int flags, char data); / * called by VFS when filesystem is remounted*/
…
};
——————————————–CODE—————————————-
Each item in the above structure is a pointer to a function that operates on a superblock object.

The Inode Object and Inode Operations

The inode object represents all the information needed by the kernel to manipulate a file or directory. Inode stores the metadata about the files and directories on the disk.
It is represented by struct inode defined in < linux / fs.h >. The important fields are reproduced below.(Listing 3)
Listing 3
——————————————–CODE—————————————-
struct inode{
…
unsigned long i_ino; /* inode number */
umode_t i_mode; /* access permissions */
unsigned int i_nlink; /* number of hard links */
uid_t i_uid; /* user id of owner */
loff_t i_size; /* file size in bytes */
struct inode_operations *i_op; /* inode operations table */
struct file_operations *f_op; /* file operations */
struct super_block *i_sb; /* associated superblock */
union{ void *generic_ip;} u; /* fs-specific info */
…
struct list_head i_devices; /* list of block Devices */
struct pipe_inode_info i_pipe; / * pipe information */
struct block_device i_bdev; / * Block Device Driver */
struct cdev i_cdev; /* Character Devcie Driver*/
…
};
——————————————–CODE—————————————-
An inode represents information about each file on a filesystem and are created in memory as the files are accessed. Also it is worthwhile to note in the above listing the last few lines. Recall that even devices and pipes are represented as files and so they must be having the corresponding inode entries. This is what is achieved by the following entries : (Table 1)

Table 1

The inode operations are defined in struct inode_operations in < linux/fs.h >. The common fields are reproduced below. (Listing 5)
Listing 4
——————————————–CODE—————————————-
struct inode_operations{
…
int (*create) (struct inode dir, struct dentry dentry, int mode); /* Create a new inode corresponding to a creat( ) or open ( ) system call */
struct dentry (*lookup) (struct inode dir, struct dentry dentry); /* Search for an inode */
int (*link) (struct dentry old_dentry, struct inode dir, struct dentry dentry); /* called by the link ( ) system call*/
int (*unlink) (struct inode dir, struct dentry dentry); /* called from unlink( ) system call */
int (*mkdir) (struct inode ,struct dentry ,int); /* called by the mkdir( ) system call */
int (*rmdir) (struct inode *,struct dentry *); /* called by the rmdir( ) system call */
int (*mknod) (struct inode *,struct dentry *,int,dev_t); /* called by the mknod( ) system call */
…
};
——————————————–CODE—————————————-

The Dentry Object and Dentry Operations

A dentry object represents a specific component in a path and usually corresponds to some inode. It is created on-the-fly from a string representation of a path name and does not correspond to any on-disk data structure and is created/used in directory-specific operations such as path name lookup
Listing 5
——————————————–CODE—————————————-
struct dentry{
…
struct inode *d_inode; /* associated inode */
struct list_head d_subdirs; /* subdirectories */
struct dentry_operations *d_op; /* dentry operations table */
struct super_block *d_sb; /*superblock of file */
void *d_fsdata; /* fs-specific data */
struct dentry *d_parent; /* dentry of parent dir */
struct qstr d_name; /* dentry name */
…
};

——————————————–CODE—————————————-
The dentry operations are declared in struct dentry_operations( Listing 6)

Listing 6
——————————————–CODE—————————————-
struct dentry_operations{
…
int (*d_revalidate) (struct dentry *, int);
int (*d_hash) (struct dentry *, struct qstr *);
int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
…
};

——————————————–CODE—————————————-

The File object and File operations

Finally, we reach the highest level of abstraction, the file. Every file that is opened by a process has a corresponding entry of the file object. It is defined as struct file in <linux/fs.h> .The important fields are reproduced here. (Listing 6)
Listing 7
——————————————–CODE—————————————-
struct file{
…
struct dentry *f_dentry; /* associated dentry object */
struct file_operations *f_op; /* file operations table */
unsigned int f_flags; /* flags specified on open */
loff_t f_pos; /* file offset(file pointer)*/
void *private_data;
…
};
——————————————–CODE—————————————-
When a file is opened using the open( ) system call a new file object is created and destroyed when close ( ) is called. These operations are specified in struct file_operations in < linux /fs.h > (Listing 7)
Listing 8
——————————————–CODE—————————————-
struct file_operations{
…
loff_t (*llseek) (struct file , loff_t int); / * llseek( ) system call */
ssize_t (*read) (struct file *, char *, size_t *, loff_t *); /* read( ) system call */
ssize_t (*write) (struct file *, const char *, size_t, loff_t *); /* write( ) system call */
int (*open) (struct inode *, struct file *); /* open( ) system call */
int (*readdir) (struct file , void dirent, filldir_t); / * readdir() system call */
…
};
——————————————–CODE—————————————-
As is apparent , the most common file operation system calls are defined here.
After this short tour of the VFS let us now seek an understanding how a filesystem is mounted

Mounting a filesystem

Note : Portions of this section has been cited from the doc available at http://www.tldp.org/LDP/tlk/fs/filesystem.html as the licence allows this
When the user attempts to mount a file system, the Linux kernel must first validate the arguments passed in the system call. Although mount does some basic checking, it does not know which file systems this kernel has been built to support or that the proposed mount point actually exists. Consider the following mount command:
$ mount -t vfat /dev/hda5 /mnt/winc
Once this command is given, the first task of the VFS is to find the type of filesystem to be mounted (vfat in this example). The VFS achieves this by browsing through the list of known file systems by looking at each file_system_type (see below) data structure in the list of supported filesystems . If a match is found it knows that this file system type is supported by this kernel and it has the address of the file system specific routine for reading this file system’s superblock. If it cannot find a matching file system name, a request is passed to the kernel daemon to load the appropriate module. (This is possible only if the kernel supports module loading).
The next task is to find the VFS inode of the directory (/mnt/winc) which is to be the new file system’s mount point. Once the inode has been found (either in the inode cache or a block device) it is checked to see that it is a directory and that there is not already some other file system mounted there.
At this point a VFS superblock must be allocated and pass the mount information to the superblock read routine for this file system. All of the system’s VFS superblocks are kept in the super_blocks vector of super_block data structures and one must be allocated for this mount. The superblock read routine must fill out the VFS superblock fields based on information that it reads from the physical device. Note that not all the fields of the superblock are used by all filesystems, some filesystems may just leave certain unused fields as NULL.
Each mounted file system is described by a vfsmount data structure( defined as struct vfsmount in linux/mount.h, Listing 9). These are queued on a list pointed at by vfsmntlist (defined in < fs/super.c >).

Listing 9
——————————————–CODE—————————————-
struct vfsmount {
struct list_head mnt_hash;
struct vfsmount *mnt_parent; /* fs we are mounted on */
struct dentry *mnt_mountpoint; /* dentry of mountpoint */
struct dentry *mnt_root; /* root of the mounted tree */
struct super_block *mnt_sb; /* pointer to superblock */
struct list_head mnt_mounts; /* list of children, anchored here */
struct list_head mnt_child; /* and going through their mnt_child */
atomic_t mnt_count;
int mnt_flags;
int mnt_expiry_mark; /* true if marked for expiry */
char *mnt_devname; /* Name of device e.g. /dev/dsk/hda1 */
struct list_head mnt_list;
struct list_head mnt_expire; /* link in fs-specific expiry list */
struct list_head mnt_share; /* circular list of shared mounts */
struct list_head mnt_slave_list; /* list of slave mounts */
struct list_head mnt_slave; /* slave list entry */
struct vfsmount *mnt_master; /* slave is on master->mnt_slave_list */
struct namespace *mnt_namespace; /* containing namespace */
int mnt_pinned;
};

——————————————–CODE—————————————-
Another pointer, vfsmnttail ( fs/super,c>) points at the last entry in the list and the mru_vfsmnt (<fs/super.c >) pointer points at the most recently used file system. Each vfsmount structure contains the device number of the block device holding the file system, the directory where this file system is mounted and a pointer to the VFS superblock allocated when this file system was mounted. In turn the VFS superblock points at the file_system_type (See Below) data structure for this sort of file system and to the root inode for this file system. This inode is kept resident in the VFS inode cache all of the time that this file system is loaded.

The file_system_type structure

Each filesystem is represented by a struct file_system_type structure defined in <linux /fs.h> (Listing 10)
Listing 10
——————————————–CODE—————————————-
struct file_system_type {
const char name; /* filesystem’s name */
int fs_flags; /* filesystem type flags */
struct super_block *(*get_sb) (struct file_system_type *, int, const char *, void *);
/* read the superblock off the disk*/
void (*kill_sb) (struct super_block *); /* terminate access to the superblock*/
struct module owner; /* module ownning the filesystem */
struct file_system_type * next; /* next filesystem in list*/
struct list_head fs_supers; /* list of superblock objects */
};

——————————————–CODE—————————————-

Footnotes

So that was a whirlwind tour of the Linux VFS wounding up with the internals of the mounting of filesystems. Implementation of a filesystem and how data lands up in the disks are unexplored territories which we will explore later. Till then happy hacking!
All code samples in this article are as in Linux kernel 2.6.15.4
References
• Linux Kernel Development, Robert Love
• Linux Kernel Source Code

Copyright @ Amit Kumar Saha

The author is a 3rd year Computer engineering undergraduate student at Haldia Institute of Technology, Haldia, India. His interests include Operating systems, Network protocols, Network security, Mobile computing.He is passionate about programming and Python is the most recent addition to the kitty of languages
Homepage: http://amitsaha.in.googlepages.com

Attached Files:

• website-mockup-tips1.zip (403 KB)