• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: calling open() on an older cd device returns EBUSY??
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: calling open() on an older cd device returns EBUSY??


  • Subject: Re: calling open() on an older cd device returns EBUSY??
  • From: Dan Markarian <email@hidden>
  • Date: Thu, 5 May 2005 14:57:24 -0400

Hi Kevin,

char dev node (i.e. disk2)

I believe the terminology is in need of a tiny bit of untangling.

/dev/disk2 is the block device, aka cooked device.  It is buffered.

/dev/rdisk2 is the character device, aka raw device.  It is unbuffered.

It is common to confuse them since the block device can read a character at a time, thanks to the buffer, and the character device can read a block at a time, thanks to no buffer.

Use the raw dev node young padawan.

Yes.  I find the term raw device best.

Dan

On 5 May 2005, at 12:41 PM, Kevin Elliott wrote:

At 19:06 -0700  on  5/4/05, David M. Cotter wrote:

  You can use opendev() to open the character device, that is, "/dev/rdisk2"

so, opendev() gives you the char device, while open() gives you the block device?  I was unsuccessful doing
open("disk2"), I *was* successful doing open("rdisk2").  Are you saying it's better to call opendev("rdisk2")?
what exactly does prepending "r" in front of the "disk2" do?


The rdisk2 is a raw dev node.  It provides block level passthrough to the underlying device- in other words, all I/O is handled directly with no caching.  If you read the same block 5 times in a row, you will get 5 reads in a row on the bus.  The only restriction is that all I/O must be block aligned, so be sure you know the block size of your media before using it (their are a variety of API's you can use to get the block size).

My recommendation is to simply avoid the char dev node (i.e. disk2) whenever possible- if you need block level access you generally don't need caching, and because the filesystem opens the char dev node, their is always the potential for weird things to happen.


correct, i just want to rip the stuff off and be done with it.  i'm not going to read it more than once.

and my apologies to anyone on the list who saw "anyone gotn'y clue here" as something like "this list is clueless",
totally honestly and humbly, i state for the record I was feeling that *I* was the utterly clueless one, just hoping
for Obi-Wan Kenobi to save me.


Use the raw dev node young padawan.  The ways of the char dev node are dark and mysterious, for the system does own it and shall block your path at every turn.  Verily I say, the raw dev node is the path of light and shall not fail you when all is dark....
-- 
__________________________________________
Kevin Elliott   <mailto:email@hidden>
Software Engineer, Intech Software Corporation
www.intechUSA.com

iChatAV/AIM: email@hidden  (video chat available)
__________________________________________


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Re: calling open() on an older cd device returns EBUSY?? (From: Kevin Elliott <email@hidden>)

  • Prev by Date: Re: calling open() on an older cd device returns EBUSY??
  • Next by Date: Re: vmmap
  • Previous by thread: Re: calling open() on an older cd device returns EBUSY??
  • Next by thread: Re: calling open() on an older cd device returns EBUSY??
  • Index(es):
    • Date
    • Thread