Binding raw devices in Linux kernel 2.6

[galapogos]

Hi,

I'm trying to port an old program compiled on kernel 2.4, onto kernel
2.6. I've using a Mandriva 2009.1 box as my development PC. I've
managed to get the program to build properly once I've gotten the
necessary libraries, and it also runs.

However, one of the first things that the program does is to bind the
raw devices(already set up as separate logical partitions within the
drive as /dev/sdaN) to /dev/rawN, in order to access them later
directly.

To do so, the first thing that it does is to open /dev/rawctl with the
following code:

if ((master_fd = open("/dev/rawctl", O_RDWR, 0)) < 0) {
  return ERR_FAILURE;
}

However, open always returns -1, hence the program fails at this
point.

Has anything changed between kernel 2.4 and 2.6 that may cause a
failure when I try to open /dev/rawctl?

Thanks!

 

[David W. Hodgins]

if ((master_fd = open("/dev/rawctl", O_RDWR, 0)) < 0) {
return ERR_FAILURE;
Has anything changed between kernel 2.4 and 2.6 that may cause a
failure when I try to open /dev/rawctl?[/QUOTE]

 From "man raw" ...

WARNING
        The rawio is a deprecated interface since Linux kernel 2.6.3. Please, modify your application to open the
        block device with the O_DIRECT flag.

Regards, Dave Hodgins

 

[Jan Kandziora]

However, one of the first things that the program does is to bind the
raw devices(already set up as separate logical partitions within the
drive as /dev/sdaN) to /dev/rawN, in order to access them later
directly.

Forgetting about "raw devices" and using O_DIRECT should do the trick. But
first read Linus' ramblings about O_DIRECT and "raw io" in general:

http://kerneltrap.org/node/7563

Kind regards

Jan

 

[galapogos]

Forgetting about "raw devices" and using O_DIRECT should do the trick. But
first read Linus' ramblings about O_DIRECT and "raw io" in general:

http://kerneltrap.org/node/7563

Kind regards

        Jan

Thanks. Does that mean that there's no way of using binding devices
to /dev/rawN? The original code author has left and I'm not sure why
raw devices were used rather than using ioctl calls.

So, by O_DIRECT, you do mean sending ioctl() to the device with
O_DIRECT flag, right?

 

[Jan Kandziora]

Thanks. Does that mean that there's no way of using binding devices
to /dev/rawN? The original code author has left and I'm not sure why
raw devices were used rather than using ioctl calls.

You could rely on this deprecated kernel feature and activate it in the
kernel of your machine, but as you said, you'll try to *port* the software
to Linux-2.6, it seems pretty straightforward to leave out raw devices
entirely.

So, by O_DIRECT, you do mean sending ioctl() to the device with
O_DIRECT flag, right?

No. O_DIRECT is applied on open(). You don't have to "bind" a raw
device /dev/raw/raw3 to a block device like /dev/sda6 using /dev/rawctl or
the "raw" utility, then use /dev/raw/raw3 instead of /dev/sda6.

Just open /dev/sda6 with O_DIRECT flag. You can even open simple files with
O_DIRECT. Make sure to

#define _GNU_SOURCE

before any #include. BUT, if you plan to really rework your application, it
may be wise to take a side look to madvise() and posix_fadvise().

Kind regards

Jan

 

[galapogos]

You could rely on this deprecated kernel feature and activate it in the
kernel of your machine, but as you said, you'll try to *port* the software
to Linux-2.6, it seems pretty straightforward to leave out raw devices
entirely.


No. O_DIRECT is applied on open(). You don't have to "bind" a raw
device /dev/raw/raw3 to a block device like /dev/sda6 using /dev/rawctl or
the "raw" utility, then use /dev/raw/raw3 instead of /dev/sda6.

Just open /dev/sda6 with O_DIRECT flag. You can even open simple files with
O_DIRECT. Make sure to

#define _GNU_SOURCE

before any #include. BUT, if you plan to really rework your application, it
may be wise to take a side look to madvise() and posix_fadvise().

Kind regards

        Jan

Thanks. It turned out I didn't enable the deprecated raw. It works
after I do so. If I run into any other problems I'll check out the
O_DIRECT. However, conservations with the original author of the code
revealed that the motivation to use raw instead of O_DIRECT was to
bypass any caching that the motherboard chipset does so that the write
happens immediately. This is important since we're dealing with timing
critical events. Apparently O_DIRECT isn't as "direct" in his
experience.