<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 2:37 PM, Greg KH <span dir="ltr"><<a href="mailto:greg@kroah.com" target="_blank">greg@kroah.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Thu, Jan 29, 2015 at 01:11:13PM -0500, David Legault wrote:<br>
> Hello,<br>
><br>
> I'm working on some linux kernel driver stuff and I have a fake path called /<br>
> dev/blah/whatever that points to /dev/block/real_device.<br>
<br>
</span>That's a userspace "path", right? Why would the kernel care about this?<br>
<span class=""><br>
> The issue is that lookup_bdev will fail to follow the symlink so I'd like to<br>
> massage the path upfront by getting the real path (/dev/block/real_device) so I<br>
> can hand that off to lookup_bdev so it returns successfully instead of an<br>
> error.<br>
<br>
</span>Why are you calling this from within the kernel? You should have a bdev<br>
already directly within the kernel, no need to muck around in /dev/<br></blockquote><div><br></div><div><span style="font-size:13px">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.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
What exactly are you doing that you feel you need access to a block<br>
device node?<br>
<br>
thanks,<br>
<br>
greg k-h<br>
</blockquote></div><br></div></div>