Entries by Bender

A question I was recently asked was, "why isn't the latest PC-Doctor for Linux release able to distinguish the differences between a USB flash drive and USB hard drive?" The answer is a bit interesting and ultimately boils down to a rather loose specification. To understand the problem, it helps to understand how USB mass storage devices work. USB mass storage devices, whether they are flash drives, hard drives, digital cameras, CDROMs, or DVD players, generally implement a small subset of SCSI commands. These commands are sent to the USB device via a special command block called a USB Request Block (URB). It is a very difficult task to properly implement the various SCSI standards and command sets properly in, and since most hardware and firmware designers want to keep development costs minimal, they often chose to only implement the commands required to make a device function. Even commands designated as MANDATORY in the SCSI specifications often go unimplemented or only partially implemented in the firmware of these devices.

There are a few SCSI commands which seem to be consistently implemented. They are listed below:

• INQUIRY


• REQUEST SENSE


• READ CAPACITY


• READ (10)


• WRITE (10)


• TEST UNIT READY

The only command relevant to our discussion is the INQUIRY command. This command is described in the SCSI Primary Command Set. This command instructs the device to send the computer information describing the device and its logical unit. The returned data conforms to the Standard INQUIRY data format and contains the following information that is of interest to most users:

• Peripheral Device Type - This field is generally set to 0x00 (Disk), 0x05 (CD/DVD device), 0x0E (some disks).


• Removable Media Bit (RMB) - This bit field can be true (1) or false (0). When set true, the medium or disk is supposed to be removable. When set to false, the medium is not removable.


• Vendor Identification - A string of 8 characters which uniquely identify the vendor of the device. Each vendor is assigned a string by INCITS.


• Product Identification - This field contains 16 ASCII characters that the vendor can name their device.


• Product Revision Level - This field contains 4 ASCII characters which the vendor can use to distinguish different revisions of their product.

There is a lot more information provided by the INQUIRY data, but the only field relevant to our discussion is the Removable Media Bit.

Most USB hard drives are actually ATA or SATA disks, hidden behind what's called a USB-ATA or USB-SATA bridge chip. This chip translates USB and SCSI commands into the appropriate command for the enclosed disk, whether it be ATA or SATA. These chips generally say that their medium is not removable, because it is a �fixed� disk and you cannot easily replace the enclosed hard drive while the USB device is plugged in.

Most USB flash drives, on the other hand, identify themselves as having removable mediums, thus setting the RMB bit to true.

So let's go back to the original question: Why isn't PC-Doctor for Linux able to distinguish the differences between a USB flash drive and USB hard drive?

With your understanding of the above-described Removable Media Bit, you might say �well, just say it's a hard drive if the RMB is set false and say it's a flash drive if the RMB is set true.� Flash drives are manufactured to falsely report their media is removable, even if its soldered to their circuit board. You'd be right, your solution would work ... to a degree.

Well, the proposed solution works only sometimes. There are devices out there which correctly identify themselves as not being removable, for example the Sandisk uDiskOnChip Embedded USB Flash Disk, which actually identifies itself truthfully by setting the RMB to false.

In such a case, the proposed solution would identify the uDiskOnChip as being a hard disk, which would make the PC-Doctor product look a little bit stupid for falsely identifying a device as something it isn't. So for the Linux product, we decided that it was better to not ask the question �is it a hard drive or flash disk?� and instead just call it simply a �USB mass storage device�.

While some consumers may find it confusing that we call their thumb/pen drive or USB hard drive a USB mass storage device instead of just a �flash disk� or �hard disk�, we are trying to be as accurate as possible given that there are no other standardized ways which we can use to distinguish differences.

For more information:

• USB Mass Storage Class - http://www.usb.org/developers/devclass_docs/usb_msc_overview_1.2.pdf


• SCSI Primary Commands 4 (SPC-4) - http://www.t10.org/ftp/t10/drafts/spc4/spc4r11.pdf


• SCSI Reduce Block Commands (RBC) - http://www.t10.org/ftp/t10/drafts/rbc/rbc-r10a.pdf

C++ is all about object oriented programming. Combined with templating, objects become generic and �reusable.� Or at least thats what your typical beginning computer science instructors will tell you in high school or college. The truth is that while objects appear reusable to you, they are rarely actually reused by your compiler. This article, the first in a series on C++ optimizations, discusses a simple way to reduce your application's code size while improving execution speed.Lets start out the article with a typical C++ class declaration for an Array template.

template < class T >
class Array {
public:
T & operator[](int n) { return m_elements[n]; }
... // Other methods
private:
T m_elements;
};

Lets say your program needs an array of integers, you would declare an instance as:

Array< int > myIntArr;

Then later in code, you find out that you need an array of unsigned integers:

Array< unsigned int > myUnsignedIntAr;

When you compile your program in C++, the compiler actually creates two full working copies of the Array class. One instance is for the integer data type, the other for the unsigned integer data type. This naturally doubles the size of your compiled code. As your C++ application gets more and more complex, the amount of binary code to implement all instances of the Array class increases significantly.

As code size goes up, you can expect performance to go down for a number of reasons. The two big ones that I often talk about is that it takes longer to initially load code from the hard drive and your CPU cannot keep very much code in its on-die cache so it has to swap it out to the main system memory.

Luckily for us C++ has a little known and rarely used set of features that can not only help us reduce our application's code size, but also improve cache-friendliness.

The first feature that we'll discuss is the concept of inline-casting with template specialization. When you have two data types, which consume the same amount of memory, you can do this method. Here is an example of how it works:

If you have an Array< int > and Array< unsigned int > both used by your program, we'll âÂ?Â?wrapâÂ?Â? one implementation within the other. First you declare your generic Array template which will handle Array<int> and then you declare a special cast version which will handle Array<unsigned int>.

The basic array with an example method to retrieve a reference to element n
of the array.

template < class T >
class Array {
public:
T & operator[](int n) { return m_elements[n]; }
... // Other methodsprivate:
T m_elements;

};
#define INTERNAL_TYPE int
#define EXTERNAL_TYPE unsigned int

template <>

class Array< EXTERNAL_TYPE > {
public:
inline EXTERNAL_TYPE & operator[](int n) { return (EXTERNAL_TYPE) m_array[n]; }
... // Other methods
private:
Array< INTERNAL_TYPE > m_array;
};

When your compiler sees the above code, it declares a generic template for Array of type T, where
T is any given type. The type unsigned int is an exception though, because it sees that the template has been specialized to have a different implementation than the generic Array<T>. We actually utilize Array<T> from within Array<unsigned int> for the member data called m_array.

Most compilers will honor your inline request and therefore automatically map down any usage of Array<unsigned int> to actually be the exact same binary code as
Array<int> when you do this.

The above example only demonstrates one relatively simple method of the Array class, but some methods of your container data type Array<T> might be amazingly complex or produce large amounts of CPU instructions during compiling. Regardless of how complex and large the implementation of Array<int> becomes, you can count on your inline cast specialization of each of Array's methods to add little or no code to your final binary application.