There isn't necessarily any difference at all.
This sometimes comes up because somebody is having trouble accessing a cd - perhaps for reading, but more likely for burning. One device node doesn't work, so they try another.
If a "ls -l" of the two devices gives the same major/minor numbers (see Understanding Unix Devices), the device IS going to behave identically in the kernel, because the major and minor numbers are all that the kernel gets. It picks the driver based on the first number and passes the second number to that driver.
Sure, some silly piece of software might insist that you use some particular name (some serial software does that) but internally, none of that matters.
And what do the minor numbers mean? Whatever the person who wrote the driver wants them to mean. For Linux, there's a good list at http://www.lanana.org/docs/device-list/devices.txt but without documentation like that or source, a minor number doesn't tell you anything.
That is especially true when looking at different operating systems. You might have noticed that tty devices have a major number of "3" on your Ubuntu Linux.On a SCO Unix system, "5" would be used. Different systems will use different schemes.
By the way, these files are NOT driver code. They are pointers to driver code in the kernel, but the actual files contain no data, only the metadata in their inode. These aren't programs, they aren't drivers, they are just pointers.
Older systems would often have device entries for devices that didn't exist. You might see /dev/lp0, /dev/lp1 and /dev/lp2 even if you had no parallel printer ports at all. Nowadays, most systems create device files as and when needed.
The driver for a (physical) block device is reading n-sized blocks, and only n-sized blocks. If it implements a raw interface, then it buffers those blocks and gives you whatever you ask for.
A block device is usually a block device because the actual hardware works that way- returning some specific number of characters whenever it is tickled appropriately. Of course a driver can hide that and make x characters become y, or could even make a phyically raw device appear to be a block device- but that doesn't change the underlying nature of the device. When you access a raw device that is actually mechanically a block device, x-sized character blocks get read.
What I am trying to get at is that this all does depend on the driver, but the underlying hardware does have some influence on it. You could easily (easy being a relative term, of course) make a block interface for tapes. It wouldn't be so easy to treat an rs232 port that way unless you also had control of whatever was feeding it. Therefor a tty port is not likely to ever be implemented as anything but a character device.
The real important differences is what routines get called- a block open gets a buffer allocated by the kernel and that's where its data is, while a raw read or write is reading or writing user space. That is an important point - a device that is physically a block device can have a driver that implements only a raw interface- and tapes are an excellent example.
As to the rules for mounting, formatting, etc., in some OS's they have become rather arbitrary because the programs themselves will ignore what you actually typed and open the corresponding block or raw device that they actually need.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2013-07-27 Tony Lawrence
The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. (Paul Graham)