News Group Posts

difference between character raw and block

devices

Date: Thu, 23 Mar 2000 20:44:19 -0500
From: Tony Lawrence <tony@aplawrence.com>
Newsgroups: comp.unix.sco.misc
Subject: Re: When is raw access appropriate

Kevin Smith wrote:
> 
> In article <38DA52AF.6596BF90@aplawrence.com> Tony Lawrence <tony@aplawrence.com> writes:
> >Michael green wrote:
> >>
> >> When should I address a device by its raw name, and when by its block
> >> access name?
> >
> >
> >It really depends upon the driver- but generally consider
> >that the block device will give you (duh!) x-sized blocks of
> >bytes with each read, whereas the raw device will allow you
> >to read less characters- one at a time if you want.
> 
> ... You spoke too soon :)  It's the other (counterintuitive) way.
> The block devices go through the normal filesystem buffering just like
> regular file io.  There are no limits re alignment and size.

Not what I was getting at- the driver for a (phyical) 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.  But you are
absolutely correct, and my comments were probably more
confusing than useful.

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 was 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 -as you noted- (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.  That's what I was trying
to impart, but I didn't do it very well.

As you note, 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, and I should have made it- a device that is
physically a block device can have a driver that implements
only a raw interface- and tapes are an excellent example.

By now we've probably completely confused the poor guy who
asked the question, but I do like your answer better because
it's probably more to the point for what he was asking- the
flow of data being more important than the mechanical
underpinning I was thinking of.

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.  

-- 
Tony Lawrence (tony@aplawrence.com)
SCO/Linux articles, help, book reviews, tests, 
job listings and more : 

2 comments

Click here to add your comments




Thu Apr 6 19:00:01 2006:   anonymous


So if you map a device via raw (i.e. raw /dev/raw/raw1 8 96), then you get character access to it, but the device itself won't see the reads/writes any differently, it just buffers differently in the kernel?
So with the advent of 2.6 deprecating the raw system, and plans to completely remove it in 2.7, if one wants to get the character access to a block device, how would they do it without using O_DIRECT when opening. I ask because I'm trying to provide a means to give a target to some I/O generating stuff that does not differentiate between block and character. Unfortunately the performance of the two access types are different, so I need a way to differentiate before I give the target to the I/O generator. So while giving it the device /dev/sdg gives me nice block access and giving it the aforementioned /dev/raw/raw1 gives me nice character access, this will soon not be the case. Also, what's up with Red Had Enterprise Linux 4 Advanced Server's raw mapping. If you've got a virtual machine with it, take a snapshot and try the following:
raw /dev/raw/raw0 0 0
it'll correctly disassociate raw0 from its device, but then, inexplicably, /dev/rawctl disappears and you can't map ANYTHING anywhere. This is driving me nuts.



Thu Apr 6 19:21:07 2006:   TonyLawrence


I haven't followed kernel development very closely, so can't really comment except to note that you are always free to do your own buffering or even your own driver.

But it does seem odd to me: they are really dropping raw access? Must be more to it than that..

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.