[PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source. - Kernel

This is a discussion on [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source. - Kernel ; Hi Joel, Greg and Co, Here is the the first working code for allowing configfs to handle symlinks from sysfs struct kobject based code. Here is the commit: passing struct kobject into generic target_core_mod subsystem plugins for locating struct block_device ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

  1. [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    Hi Joel, Greg and Co,

    Here is the the first working code for allowing configfs to handle
    symlinks from sysfs struct kobject based code. Here is the commit:
    passing struct kobject into generic target_core_mod subsystem plugins
    for locating struct block_device and struct scsi_device..

    -------------------------------------------------------------------------

    In struct configfs_item_operations, added allow_link_kobject() and
    drop_link_kobject() to allow struct kobject to be passed through
    the configfs API. The code for kobject symlink source sits along side
    the exist configfs symlink code, and does not break existing apps that use
    allow_link() or drop_link().

    Also, there is two large FIXMEs with the first commit, in
    fs/configfs/symlink.c:configfs_symlink() related to comparing
    struct nameidata nd.path.dentry->d_sb == sysfs_sb.

    The 2nd is when doing a 'ls -la' inside of the config group directory
    containg the symlink source from sysfs, the source link does not currently
    appear.. I will be following up these two items..

    Signed-off-by: Nicholas A. Bellinger
    ---
    fs/configfs/configfs_internal.h | 3 +-
    fs/configfs/symlink.c | 168 +++++++++++++++++++++++++++------------
    include/linux/configfs.h | 6 +-
    3 files changed, 123 insertions(+), 54 deletions(-)

    the following commit can be found at:

    http://git.kernel.org/?p=linux/kerne...ef9467b6f0c9ba

    Comments..? I will send along my patch to
    drivers/lio-core/target_core_configfs.c in a moment to demonstrate how
    to pull it all together with struct config_item_operations
    allow_link_kobject() and drop_link_kobject()..


  2. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > Hi Joel, Greg and Co,
    >
    > Here is the the first working code for allowing configfs to handle
    > symlinks from sysfs struct kobject based code. Here is the commit:
    > passing struct kobject into generic target_core_mod subsystem plugins
    > for locating struct block_device and struct scsi_device..


    Um, no.

    You are trying to create symlinks dynamically across superblocks and
    mount points? As one of your #warning states, this isn't possible to do
    correctly, nor is it even a good idea.

    So I'd have to reject this patch, sorry.

    What is the problem you are attempting to solve here?

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > > Hi Joel, Greg and Co,
    > >
    > > Here is the the first working code for allowing configfs to handle
    > > symlinks from sysfs struct kobject based code. Here is the commit:
    > > passing struct kobject into generic target_core_mod subsystem plugins
    > > for locating struct block_device and struct scsi_device..

    >
    > Um, no.
    >
    > You are trying to create symlinks dynamically across superblocks and
    > mount points? As one of your #warning states, this isn't possible to do
    > correctly, nor is it even a good idea.
    >
    > So I'd have to reject this patch, sorry.
    >
    > What is the problem you are attempting to solve here?
    >


    So, the generic target_core_mod engine that lives
    under /sys/kernel/config/target/core needs a method to locate struct
    block_device and struct scsi_device for access via bio_submit() and
    scsi_execute_() respectively.

    Originally, target_core_mod used key echoed through configfs attributes
    like so:

    export TARGET=/sys/kernel/config/target/core/

    # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    mkdir -p $TARGET/iblock_0/lvm_test0
    # OLD METHOD to reference struct block_device
    echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    echo 1 > $TARGET/iblock_0/lvm_test0/enable
    # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2

    # Create $STORAGE_OBJET of type Linux/SCSI in generic target_core_mod
    mkdir -p $TARGET/pscsi_0/sdd
    # OLD METHOD to reference struct scsi_device
    echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/control
    echo 1 > $TARGET/pscsi_0/sdd/enable
    # NEW METHOD using sysfs -> configfs symlinks to reference struct scsi_device
    ln -s /sys/block/sdd/device $TARGET/pscsi_0/sdd/passthrough

    This of course means that non TYPE_DISK of struct scsi_device would need
    to appear under /sys/ to be referenced using the symlink method.. I
    know that drivers/scsi/sr.c currently does not show up under /sys..

    Anyways, the idea is that its *ONLY* this special case for struct
    kobject as symlink source to struct config_item as symlink destination
    through the config struct config_item_operations API.. For the generic
    target_core_mod engine case, it seems like a good method to reference
    block and scsi related data structures for struct devices that folks
    want to use for target export across one or more $FABRIC modules (iSCSI,
    SAS, FC, PSCSI, etc)..

    I am more than happy to change the patch if there is a better way to get
    the same functionality for target_core_mod I would really not prefer
    having to do targetfs, when configfs + sysfs symlinks seems to work in
    my first few hours of testing, unless there is something huge that I am
    missing..?.

    The other point is that since configfs is based on sysfs code, it only
    makes sense to provide a API through configfs to take advantage of
    kernel data structures that can be referenced using wrappers to
    container_of() in include/linux/ in a common way.

    --nab

    > thanks,
    >
    > greg k-h
    >


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > This of course means that non TYPE_DISK of struct scsi_device would need
    > to appear under /sys/ to be referenced using the symlink method.. I
    > know that drivers/scsi/sr.c currently does not show up under /sys..


    Hmm?

    $ ls -l /sys/block/sr0/
    total 0
    lrwxrwxrwx 1 root root 0 2008-10-17 07:30 bdi -> ../../class/bdi/11:0
    -r--r--r-- 1 root root 4096 2008-10-17 07:30 capability
    -r--r--r-- 1 root root 4096 2008-10-17 07:30 dev
    lrwxrwxrwx 1 root root 0 2008-10-17 07:30 device -> ../../devices/pci0000:00/0000:00:1f.1/host3/target3:0:0/3:0:0:0
    drwxr-xr-x 2 root root 0 2008-10-17 07:30 holders
    drwxr-xr-x 2 root root 0 2008-10-17 07:30 power
    drwxr-xr-x 3 root root 0 2008-10-17 07:30 queue
    -r--r--r-- 1 root root 4096 2008-10-17 07:30 range
    -r--r--r-- 1 root root 4096 2008-10-17 07:30 removable
    -r--r--r-- 1 root root 4096 2008-10-17 07:30 ro
    -r--r--r-- 1 root root 4096 2008-10-17 07:30 size
    drwxr-xr-x 2 root root 0 2008-10-17 07:30 slaves
    -r--r--r-- 1 root root 4096 2008-10-17 07:30 stat
    lrwxrwxrwx 1 root root 0 2008-10-17 07:30 subsystem -> ../../block
    -rw-r--r-- 1 root root 4096 2008-10-17 07:30 uevent

    --
    Matthew Wilcox Intel Open Source Technology Centre
    "Bill, look, we understand that you're interested in selling us this
    operating system, but compare it to ours. We can't possibly take such
    a retrograde step."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > > > Hi Joel, Greg and Co,
    > > >
    > > > Here is the the first working code for allowing configfs to handle
    > > > symlinks from sysfs struct kobject based code. Here is the commit:
    > > > passing struct kobject into generic target_core_mod subsystem plugins
    > > > for locating struct block_device and struct scsi_device..

    > >
    > > Um, no.
    > >
    > > You are trying to create symlinks dynamically across superblocks and
    > > mount points? As one of your #warning states, this isn't possible to do
    > > correctly, nor is it even a good idea.
    > >
    > > So I'd have to reject this patch, sorry.
    > >
    > > What is the problem you are attempting to solve here?
    > >

    >
    > So, the generic target_core_mod engine that lives
    > under /sys/kernel/config/target/core needs a method to locate struct
    > block_device and struct scsi_device for access via bio_submit() and
    > scsi_execute_() respectively.


    Then just pass the "name" of the block device into a configfs file,
    nothing more is needed, right?

    > Originally, target_core_mod used key echoed through configfs attributes
    > like so:
    >
    > export TARGET=/sys/kernel/config/target/core/
    >
    > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    > mkdir -p $TARGET/iblock_0/lvm_test0
    > # OLD METHOD to reference struct block_device
    > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    > echo 1 > $TARGET/iblock_0/lvm_test0/enable
    > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2


    No, you can't do a symlink across superblocks and expect it to work like
    you are thinking internally.

    > The other point is that since configfs is based on sysfs code, it only
    > makes sense to provide a API through configfs to take advantage of
    > kernel data structures that can be referenced using wrappers to
    > container_of() in include/linux/ in a common way.


    No, just because configfs looks like sysfs internally, does not mean
    they are related in any manner. We have been down this argument many
    times in the past, please don't bring it up again, it has no bearing on
    this at all.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, 2008-10-17 at 05:32 -0600, Matthew Wilcox wrote:
    > On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > > This of course means that non TYPE_DISK of struct scsi_device would need
    > > to appear under /sys/ to be referenced using the symlink method.. I
    > > know that drivers/scsi/sr.c currently does not show up under /sys..

    >
    > Hmm?
    >
    > $ ls -l /sys/block/sr0/
    > total 0
    > lrwxrwxrwx 1 root root 0 2008-10-17 07:30 bdi -> ../../class/bdi/11:0
    > -r--r--r-- 1 root root 4096 2008-10-17 07:30 capability
    > -r--r--r-- 1 root root 4096 2008-10-17 07:30 dev
    > lrwxrwxrwx 1 root root 0 2008-10-17 07:30 device -> ../../devices/pci0000:00/0000:00:1f.1/host3/target3:0:0/3:0:0:0
    > drwxr-xr-x 2 root root 0 2008-10-17 07:30 holders
    > drwxr-xr-x 2 root root 0 2008-10-17 07:30 power
    > drwxr-xr-x 3 root root 0 2008-10-17 07:30 queue
    > -r--r--r-- 1 root root 4096 2008-10-17 07:30 range
    > -r--r--r-- 1 root root 4096 2008-10-17 07:30 removable
    > -r--r--r-- 1 root root 4096 2008-10-17 07:30 ro
    > -r--r--r-- 1 root root 4096 2008-10-17 07:30 size
    > drwxr-xr-x 2 root root 0 2008-10-17 07:30 slaves
    > -r--r--r-- 1 root root 4096 2008-10-17 07:30 stat
    > lrwxrwxrwx 1 root root 0 2008-10-17 07:30 subsystem -> ../../block
    > -rw-r--r-- 1 root root 4096 2008-10-17 07:30 uevent
    >


    Oh good, I guess I missed that this has been added a while ago for
    TYPE_CDROM. I had been looking at trying to change something with sr0 a
    while back, I think it was an incorrectly set max_sectors on the
    Playstation3, but I could not find the was to do this with TYPE_CDROM as
    is possible with TYPE_DISK.

    So now that those two work, what about other SCSI device types that
    appear as character devices? The most obvious ones that come to mind
    are TYPE_MEDIUM_CHANGER and TYPE_TAPE. As they do not appear
    under /sys/block, to enable the SCSI passthrough for target_core_mod
    using symlinks from sysfs -> configfs using the patch, the sysfs source
    needs to point to struct device.. For example, with the current code,
    the export of sr0 would now look like:

    # Enable sr0 for DVD target passthrough access
    mkdir $TARGET/core/pscsi_0/dvd_rom
    ln -s /sys/block/sr0/device $TARGET/core/pscsi_0/dvd_rom/dvd_passthrough

    So what about for TYPE_TYPE..? I am guessing you would need to grab the
    struct device (to reference the struct scsi_device by struct kobject
    using the configfs patch) through /sys/class/$SCSI_HCTL/device, for the
    SCSI passthrough case, right..?

    # Also enable a SCSI tape for target passthrough access..?
    mkdir $TARGET/core/pscsi_1/my_superturbotapearray
    ln -s /sys/class/1:0:0:0/device $TARGET/core/pscsi_1/my_superturbotapearray/tape_passthrough

    # MEDIUM_CHANGER too..?
    mkdir $TARGET/core/pscsi_1/my_superturbomc
    ln -s /sys/class/1:0:1:0/device $TARGET/core/pscsi_1/my_superturbomc/mc_passthrough

    I don't have real MEDIUM_CHANGER onsite, so if anyone wanted to test
    this with my current patches in lio-core-2.6.git please let me know.
    I will try hooking up my old SCSI tape drive this weekend and see if
    TYPE_TAPE works. :-)

    The idea is through the change to allow sysfs source symlinks (the patch
    still needs to handle follow_link() correctly) to pass any struct
    kobject through the configfs struct config_item_operations API while
    calling kobject_get() and kobject_put() to protect/release the reference
    to struct kobject inside of fs/configfs/symlink.c.

    --nab

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, 2008-10-17 at 10:39 -0700, Greg KH wrote:
    > On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > > > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > > > > Hi Joel, Greg and Co,
    > > > >
    > > > > Here is the the first working code for allowing configfs to handle
    > > > > symlinks from sysfs struct kobject based code. Here is the commit:
    > > > > passing struct kobject into generic target_core_mod subsystem plugins
    > > > > for locating struct block_device and struct scsi_device..
    > > >
    > > > Um, no.
    > > >
    > > > You are trying to create symlinks dynamically across superblocks and
    > > > mount points? As one of your #warning states, this isn't possible to do
    > > > correctly, nor is it even a good idea.
    > > >
    > > > So I'd have to reject this patch, sorry.
    > > >
    > > > What is the problem you are attempting to solve here?
    > > >

    > >
    > > So, the generic target_core_mod engine that lives
    > > under /sys/kernel/config/target/core needs a method to locate struct
    > > block_device and struct scsi_device for access via bio_submit() and
    > > scsi_execute_() respectively.

    >
    > Then just pass the "name" of the block device into a configfs file,
    > nothing more is needed, right?
    >


    What are the preferred methods for accessing struct block_device and
    struct scsi_device from "name"..?

    > > Originally, target_core_mod used key echoed through configfs attributes
    > > like so:
    > >
    > > export TARGET=/sys/kernel/config/target/core/
    > >
    > > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    > > mkdir -p $TARGET/iblock_0/lvm_test0
    > > # OLD METHOD to reference struct block_device
    > > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    > > echo 1 > $TARGET/iblock_0/lvm_test0/enable
    > > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    > > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2

    >
    > No, you can't do a symlink across superblocks and expect it to work like
    > you are thinking internally.
    >


    As I am coding configfs_follow_symlink() to work with sysfs
    source symlinks I am starting to see that.. :-) I am still going to
    hack on it for a bit and see if I can get it running so that it works..

    > > The other point is that since configfs is based on sysfs code, it only
    > > makes sense to provide a API through configfs to take advantage of
    > > kernel data structures that can be referenced using wrappers to
    > > container_of() in include/linux/ in a common way.

    >
    > No, just because configfs looks like sysfs internally, does not mean
    > they are related in any manner. We have been down this argument many
    > times in the past, please don't bring it up again, it has no bearing on
    > this at all.
    >


    Well, the goal is to use as much existing infrastructure as possible for
    the generic target_core_mod when referencing Linux $STORAGE_OBJECTs, be
    they struct scsi_device, struct block_device or struct file.. :-)

    Having *SOME* type of communication between sysfs and configfs so that
    those kernel data structures mentioned above can be accessed through
    configfs still does seem like it could be useful..

    Thanks for your comments,

    --nab


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > Hi Joel, Greg and Co,
    >
    > Here is the the first working code for allowing configfs to handle
    > symlinks from sysfs struct kobject based code. Here is the commit:
    > passing struct kobject into generic target_core_mod subsystem plugins
    > for locating struct block_device and struct scsi_device..


    NAK.

    As Greg said, this just doesn't work. Don't go down this path.

    Joel

    --

    "I always thought the hardest questions were those I could not answer.
    Now I know they are the ones I can never ask."
    - Charlie Watkins

    Joel Becker
    Principal Software Developer
    Oracle
    E-mail: joel.becker@oracle.com
    Phone: (650) 506-8127
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, 2008-10-17 at 12:39 -0700, Joel Becker wrote:
    > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > > Hi Joel, Greg and Co,
    > >
    > > Here is the the first working code for allowing configfs to handle
    > > symlinks from sysfs struct kobject based code. Here is the commit:
    > > passing struct kobject into generic target_core_mod subsystem plugins
    > > for locating struct block_device and struct scsi_device..

    >
    > NAK.
    >
    > As Greg said, this just doesn't work. Don't go down this path.
    >


    Fair enough, I will kill it from my tree. :-)

    Thanks for your comments!

    --nab



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > > What is the problem you are attempting to solve here?
    > >

    >
    > So, the generic target_core_mod engine that lives
    > under /sys/kernel/config/target/core needs a method to locate struct
    > block_device and struct scsi_device for access via bio_submit() and
    > scsi_execute_() respectively.
    >
    > Originally, target_core_mod used key echoed through configfs attributes
    > like so:
    >
    > export TARGET=/sys/kernel/config/target/core/
    >
    > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    > mkdir -p $TARGET/iblock_0/lvm_test0
    > # OLD METHOD to reference struct block_device
    > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    > echo 1 > $TARGET/iblock_0/lvm_test0/enable
    > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2


    Pass an open file descriptor. In bash(1):

    exec 3<>/dev/dm-7
    echo 3 >$TARGET/iblock_0/lvm_test0/control # I'd call it 'fd'

    In kernel, in the ->store() function of 'control':

    p = (char *)page;
    fd = simple_strtol(p, &p, 0);
    filp = fget(fd);
    inode = igrab(filp->f_mapping->host);
    dev = I_BDEV(filp->f_mapping->host);
    blkdev_get(dev, FMODE_WRITE | FMODE_READ, 0);

    Error handling is left up to you (validate the strtol, fd range, ISBLK,
    etc). This assumes you want the struct block_device and want to pin it
    in memory. I assume you do.

    Joel

    --

    Life's Little Instruction Book #450

    "Don't be afraid to say, 'I need help.'"

    Joel Becker
    Principal Software Developer
    Oracle
    E-mail: joel.becker@oracle.com
    Phone: (650) 506-8127
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, 2008-10-17 at 12:48 -0700, Joel Becker wrote:
    > On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > > > What is the problem you are attempting to solve here?
    > > >

    > >
    > > So, the generic target_core_mod engine that lives
    > > under /sys/kernel/config/target/core needs a method to locate struct
    > > block_device and struct scsi_device for access via bio_submit() and
    > > scsi_execute_() respectively.
    > >
    > > Originally, target_core_mod used key echoed through configfs attributes
    > > like so:
    > >
    > > export TARGET=/sys/kernel/config/target/core/
    > >
    > > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    > > mkdir -p $TARGET/iblock_0/lvm_test0
    > > # OLD METHOD to reference struct block_device
    > > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    > > echo 1 > $TARGET/iblock_0/lvm_test0/enable
    > > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    > > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2

    >
    > Pass an open file descriptor. In bash(1):
    >
    > exec 3<>/dev/dm-7
    > echo 3 >$TARGET/iblock_0/lvm_test0/control # I'd call it 'fd'
    >
    > In kernel, in the ->store() function of 'control':
    >
    > p = (char *)page;
    > fd = simple_strtol(p, &p, 0);
    > filp = fget(fd);
    > inode = igrab(filp->f_mapping->host);
    > dev = I_BDEV(filp->f_mapping->host);
    > blkdev_get(dev, FMODE_WRITE | FMODE_READ, 0);
    >
    > Error handling is left up to you (validate the strtol, fd range, ISBLK,
    > etc). This assumes you want the struct block_device and want to pin it
    > in memory. I assume you do.
    >


    Btw, ideally I would like to do the same type of thing for accessing
    drivers/scsi for both TYPE_DISK and non TYPE_DISK.. I will have a look
    and see if something is possible to access struct scsi_device in all
    device type cases..

    --nab

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, 2008-10-17 at 12:48 -0700, Joel Becker wrote:
    > On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > > > What is the problem you are attempting to solve here?
    > > >

    > >
    > > So, the generic target_core_mod engine that lives
    > > under /sys/kernel/config/target/core needs a method to locate struct
    > > block_device and struct scsi_device for access via bio_submit() and
    > > scsi_execute_() respectively.
    > >
    > > Originally, target_core_mod used key echoed through configfs attributes
    > > like so:
    > >
    > > export TARGET=/sys/kernel/config/target/core/
    > >
    > > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    > > mkdir -p $TARGET/iblock_0/lvm_test0
    > > # OLD METHOD to reference struct block_device
    > > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    > > echo 1 > $TARGET/iblock_0/lvm_test0/enable
    > > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    > > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2

    >
    > Pass an open file descriptor. In bash(1):
    >
    > exec 3<>/dev/dm-7
    > echo 3 >$TARGET/iblock_0/lvm_test0/control # I'd call it 'fd'
    >
    > In kernel, in the ->store() function of 'control':
    >
    > p = (char *)page;
    > fd = simple_strtol(p, &p, 0);
    > filp = fget(fd);
    > inode = igrab(filp->f_mapping->host);
    > dev = I_BDEV(filp->f_mapping->host);
    > blkdev_get(dev, FMODE_WRITE | FMODE_READ, 0);
    >
    > Error handling is left up to you (validate the strtol, fd range, ISBLK,
    > etc). This assumes you want the struct block_device and want to pin it
    > in memory. I assume you do.
    >


    Sounds good.. I will go about converting the target_core_mod
    subsystem plugins to use this method..

    Thanks Joel!

    --nab

    > Joel
    >


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, Oct 17, 2008 at 12:19:33PM -0700, Nicholas A. Bellinger wrote:
    > On Fri, 2008-10-17 at 10:39 -0700, Greg KH wrote:
    > > On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > > > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > > > > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > > > > > Hi Joel, Greg and Co,
    > > > > >
    > > > > > Here is the the first working code for allowing configfs to handle
    > > > > > symlinks from sysfs struct kobject based code. Here is the commit:
    > > > > > passing struct kobject into generic target_core_mod subsystem plugins
    > > > > > for locating struct block_device and struct scsi_device..
    > > > >
    > > > > Um, no.
    > > > >
    > > > > You are trying to create symlinks dynamically across superblocks and
    > > > > mount points? As one of your #warning states, this isn't possible to do
    > > > > correctly, nor is it even a good idea.
    > > > >
    > > > > So I'd have to reject this patch, sorry.
    > > > >
    > > > > What is the problem you are attempting to solve here?
    > > > >
    > > >
    > > > So, the generic target_core_mod engine that lives
    > > > under /sys/kernel/config/target/core needs a method to locate struct
    > > > block_device and struct scsi_device for access via bio_submit() and
    > > > scsi_execute_() respectively.

    > >
    > > Then just pass the "name" of the block device into a configfs file,
    > > nothing more is needed, right?
    > >

    >
    > What are the preferred methods for accessing struct block_device and
    > struct scsi_device from "name"..?


    call "find_by_name" for a type (this would be block type) and get the
    return value? Can't remember the actual function call, but it's obvious
    if you look at device.h.

    > > > Originally, target_core_mod used key echoed through configfs attributes
    > > > like so:
    > > >
    > > > export TARGET=/sys/kernel/config/target/core/
    > > >
    > > > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    > > > mkdir -p $TARGET/iblock_0/lvm_test0
    > > > # OLD METHOD to reference struct block_device
    > > > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    > > > echo 1 > $TARGET/iblock_0/lvm_test0/enable
    > > > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    > > > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2

    > >
    > > No, you can't do a symlink across superblocks and expect it to work like
    > > you are thinking internally.
    > >

    >
    > As I am coding configfs_follow_symlink() to work with sysfs
    > source symlinks I am starting to see that.. :-) I am still going to
    > hack on it for a bit and see if I can get it running so that it works..


    Even if you get it "to work", it's not going to be able to be accepted,
    sorry.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

    On Fri, 2008-10-17 at 13:10 -0700, Greg KH wrote:
    > On Fri, Oct 17, 2008 at 12:19:33PM -0700, Nicholas A. Bellinger wrote:
    > > On Fri, 2008-10-17 at 10:39 -0700, Greg KH wrote:
    > > > On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
    > > > > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
    > > > > > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
    > > > > > > Hi Joel, Greg and Co,
    > > > > > >
    > > > > > > Here is the the first working code for allowing configfs to handle
    > > > > > > symlinks from sysfs struct kobject based code. Here is the commit:
    > > > > > > passing struct kobject into generic target_core_mod subsystem plugins
    > > > > > > for locating struct block_device and struct scsi_device..
    > > > > >
    > > > > > Um, no.
    > > > > >
    > > > > > You are trying to create symlinks dynamically across superblocks and
    > > > > > mount points? As one of your #warning states, this isn't possible to do
    > > > > > correctly, nor is it even a good idea.
    > > > > >
    > > > > > So I'd have to reject this patch, sorry.
    > > > > >
    > > > > > What is the problem you are attempting to solve here?
    > > > > >
    > > > >
    > > > > So, the generic target_core_mod engine that lives
    > > > > under /sys/kernel/config/target/core needs a method to locate struct
    > > > > block_device and struct scsi_device for access via bio_submit() and
    > > > > scsi_execute_() respectively.
    > > >
    > > > Then just pass the "name" of the block device into a configfs file,
    > > > nothing more is needed, right?
    > > >

    > >
    > > What are the preferred methods for accessing struct block_device and
    > > struct scsi_device from "name"..?

    >
    > call "find_by_name" for a type (this would be block type) and get the
    > return value? Can't remember the actual function call, but it's obvious
    > if you look at device.h.
    >


    Got it, thanks..

    > > > > Originally, target_core_mod used key echoed through configfs attributes
    > > > > like so:
    > > > >
    > > > > export TARGET=/sys/kernel/config/target/core/
    > > > >
    > > > > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
    > > > > mkdir -p $TARGET/iblock_0/lvm_test0
    > > > > # OLD METHOD to reference struct block_device
    > > > > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
    > > > > echo 1 > $TARGET/iblock_0/lvm_test0/enable
    > > > > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
    > > > > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2
    > > >
    > > > No, you can't do a symlink across superblocks and expect it to work like
    > > > you are thinking internally.
    > > >

    > >
    > > As I am coding configfs_follow_symlink() to work with sysfs
    > > source symlinks I am starting to see that.. :-) I am still going to
    > > hack on it for a bit and see if I can get it running so that it works..

    >
    > Even if you get it "to work", it's not going to be able to be accepted,
    > sorry.
    >


    not a problem, it was just something that I wanted to see if it
    was even possible. I will refocus on using the method to locate what
    Linux storage objects can be used for target_core_mod that Joel
    mentioned and your recommendations.

    Thanks,

    --nab

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread