Linux Kernel readlink equivalent
Hello, I'm working on some linux kernel driver stuff and I have a fake path called /dev/blah/whatever that points to /dev/block/real_device. The issue is that lookup_bdev will fail to follow the symlink so I'd like to massage the path upfront by getting the real path (/dev/block/real_device) so I can hand that off to lookup_bdev so it returns successfully instead of an error. Or any other kernel call that would correctly retrieve the block_device information given the initial path which is a symlink. Note: I saw that the tomoyo module has something like that but I was looking for the generic implementation of the kernel if one exists. Thanks David
On Thu, 29 Jan 2015 13:11:13 -0500, David Legault said:
I'm working on some linux kernel driver stuff and I have a fake path called /dev/blah/whatever that points to /dev/block/real_device.
And *why* is kernel code trying to follow a symlink, anyhow? (Hint: there's probably (a) data you want at the other end of the symlink and (b) a better kernel API for getting at that data, which is why you can't find examples of following symlinks. ;)
On Thu, Jan 29, 2015 at 01:11:13PM -0500, David Legault wrote:
Hello,
I'm working on some linux kernel driver stuff and I have a fake path called / dev/blah/whatever that points to /dev/block/real_device.
That's a userspace "path", right? Why would the kernel care about this?
The issue is that lookup_bdev will fail to follow the symlink so I'd like to massage the path upfront by getting the real path (/dev/block/real_device) so I can hand that off to lookup_bdev so it returns successfully instead of an error.
Why are you calling this from within the kernel? You should have a bdev already directly within the kernel, no need to muck around in /dev/ What exactly are you doing that you feel you need access to a block device node? thanks, greg k-h
On Thu, Jan 29, 2015 at 2:37 PM, Greg KH <greg@kroah.com> wrote:
On Thu, Jan 29, 2015 at 01:11:13PM -0500, David Legault wrote:
Hello,
I'm working on some linux kernel driver stuff and I have a fake path called / dev/blah/whatever that points to /dev/block/real_device.
That's a userspace "path", right? Why would the kernel care about this?
The issue is that lookup_bdev will fail to follow the symlink so I'd like to massage the path upfront by getting the real path (/dev/block/real_device) so I can hand that off to lookup_bdev so it returns successfully instead of an error.
Why are you calling this from within the kernel? You should have a bdev already directly within the kernel, no need to muck around in /dev/
The path used is generic in that it never changes, but the pointed block device underneath changes based on the hardware/configuration in place. So the idea was to load a module passing the path as a module argument so I could access the underlying block device through the link without having to worry about the real block device path.
What exactly are you doing that you feel you need access to a block device node?
thanks,
greg k-h
On Fri, 30 Jan 2015 11:02:01 -0500, David Legault said:
the idea was to load a module passing the path as a module argument so I could access the underlying block device through the link without having to worry about the real block device path.
I hope you realize that scribbling on a block device without making *damned* sure you're talking to the right *real* block device is just asking for data corruption, right? What problem are you *really* trying to solve here? It sounds like your design has some serious layering violations....
On Fri, Jan 30, 2015 at 11:02:01AM -0500, David Legault wrote:
The path used is generic in that it never changes, but the pointed block device underneath changes based on the hardware/configuration in place. So the idea was to load a module passing the path as a module argument so I could access the underlying block device through the link without having to worry about the real block device path.
I don't understand at all. What exactly are you trying to create here? And don't use a module parameter for anything, you are limiting yourself to only one "device" that way, as well as preventing any distro from ever using your code. What's wrong with just using the device mapper interface in the kernel for whatever you are trying to do, instead of creating a new user api? greg k-h
Hello,
I'm working on some linux kernel driver stuff and I have a fake path called /dev/blah/whatever that points to /dev/block/real_device.
The issue is that lookup_bdev will fail to follow the symlink so I'd like to massage the path upfront by getting the real path (/dev/block/real_device) so I can hand that off to lookup_bdev so it returns successfully instead of an error.
Or any other kernel call that would correctly retrieve the block_device information given the initial path which is a symlink.
Note: I saw that the tomoyo module has something like that but I was looking for the generic implementation of the kernel if one exists.
Thanks
David
David,
1 - Please read through: *man 2 readlink* ( yes please read it *all* very carefully ! 2 - There is a system call readlink study it... declared here: http://code.woboq.org/linux/include/unistd.h.html#809 exported here: http://code.woboq.org/linux/linux/arch/um/os-Linux/user_syms.c.html#83 3 grep through the kernel and see where and how readlink is used. Try : find . -name "*.[ch]" | xargs grep "readlink" and : find . -name "*.[ch]" | xargs grep " readlink(" and : find . -name "*.[ch]" | xargs grep ">readlink" 4 - This will help you figure how to work things out <http://www.informit.com/articles/article.aspx?p=23618&seqNum=12> use at your own risk :) Good luck - Aruna
participants (4)
-
Aruna Hewapathirane -
David Legault -
Greg KH -
Valdis.Kletnieks＠vt.edu