Linux Kernel readlink equivalent

Linux Kernel readlink equivalent

[David Legault]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150129/c370e541/attachment.html 

Linux Kernel readlink equivalent

[Valdis.Kletnieks at vt.edu]

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. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150129/32e96d4a/attachment.bin 

Linux Kernel readlink equivalent

[Greg KH]

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

Linux Kernel readlink equivalent

[Aruna Hewapathirane]

>>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150130/be9e6b61/attachment.html 

Linux Kernel readlink equivalent

[David Legault]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150130/773d3140/attachment.html 

Linux Kernel readlink equivalent

[Valdis.Kletnieks at vt.edu]

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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150130/01e21729/attachment.bin 

Linux Kernel readlink equivalent

[Greg KH]

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