Block device I/O under linux, can someone point me in the right direction?

Hello everybody!

Well, I have been doing a lot of reading about the Linux kernel and am currently interested in writing some programs that perform low level block device IO. Specifically, I want to write a simple ISO burning program to burn an image made from mkisofs. The problem I am having is that I don't know where to turn next for reference material, mostly concerning actual implementation of device I/O with non character devices. For instance, where can I find good reference material for devices I am trying to program for? Do companies like Memorex have documentation available for their drives? I have read books that touch on block device I/O and most of them are far too vague to tell me what I want.

Basically what I am asking is for someone to possibly save me some time researching everything. For now I am reading through the source code to wodim (a cdrecord like program) but this is obviously not the ideal way to learn how block device IO is actually implemented. I have started reading some books, one of which is Linux Device Drivers, and this is a very good book but at the moment I am concentrating on a higher level. I want to use linux/cdrom.h to do this and I feel that I am just missing some reading that could really help me get going.

Thanks for reading this spur of the moment post, and I hope everyone understands what I mean when I say I am lacking reference material.

This seems like it might help (from the intro page anyway).
http://www.advancedlinuxprogramming.com/

I think I may have skipped over that one since it is so commonly title. Anyway, I looks like a good resource, plus its a free online book!

Well, I think that book as well doesn't go where I want.

It briefly mentions open(),read(),write() and related calls and their uses. I need to know how to use those same functions, but to properly initialize a cd drive first and then write data to that drive. A lot of resources I find aren't helping me much. Reading through the wodim source code is telling me a lot, but there is also way more information their than I am actually after. So I am sifting through lots of un-wanted code.

I had a quick look at http://lxr.linux.no/source/drivers/cdrom/cdrom.c

But it looks like writes are actually performed through the regular IDE/SCSI interface.

--
Mats

Quote:

---

Originally Posted by matsp

I had a quick look at http://lxr.linux.no/source/drivers/cdrom/cdrom.c

But it looks like writes are actually performed through the regular IDE/SCSI interface.

--
Mats

---

Thats the information I am after. A good reference for reading/writing to devices under the IDE/SCSI interface. Like I said, I am learning everything here quite slow since I am doing so much looking in other code.

You really shouldn't have to know about the intrernals of the SCSI or IDE controller. You should be able to do all you need by a combination of open, ioctl, read, write and close.

The reason I was looking at the CDROM driver was to try to determine if there was a special IOCTL to call for enabling write on the CDROM - it seems that there isn't.

--
Mats

Yes. I see that. The problem I am having is this.

I know I need to open() the device, and then write my data, but doing this as if it were another normal file does not work. I need to use a combination of ioctl() calls as preparation and then write() my data. What I need to research is how to know that actual procedure for doing so with a given device?

For instance: With X brand CDRW drive you need to call A,B, and C iotctl() calls before a write.

Now I know how I will need to deal with sectors of bytes, however, my confusion lies in the specific interaction with the hardware.

UPDATE:

Well, I finally found what I was looking for. I wanted to write a program that burns a compact disc. I just got quite confused because I jumped head first into digging through source code and sort of got lost.

Anyway, I found the Linux SCSI driver, sg:

Linux SCSI Driver HOWTO

Hopefully this post helps someone else in the future.