[lkml]   [2008]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][RFC 5/23]: SCST /proc interface
    Nicholas A. Bellinger wrote:
    > On Wed, 2008-12-10 at 21:37 +0300, Vladislav Bolkhovitin wrote:
    >> This patch contains SCST the /proc interface.
    >> A description of this interface can be found in the patch with the
    >> SCST core documentation.
    >> Since a procfs-based configuration interface is unacceptable for new
    >> kernel modules, in the next review iteration SCST's configuration
    >> interface will be replaced by a sysfs-based configuration interface.
    >> This patch is not intended to be included in the Linux kernel, but is
    >> posted here, because as of today this configuration interface is
    >> necessary when using SCST.
    >> Unfortunately, configfs is not (yet) suited for configuring SCST. This
    >> is, because configfs is user space driven, so kernel can't create
    >> subdirectories on it, and all files on configfs are limited to 4K in
    >> size. It makes impossible for kernel to show, e.g., a list of connected
    >> initiators. Hence, with configfs it is necessary to have one more
    >> interface to show such data, e.g. sysfs-based.
    > Btw, please stop spreading FUD about ConfigFS. ConfigFS works great for
    > Target_Core_Mod and LIO-Target v3.0, and is what I have found as the
    > *BEST* foundation for generic target mod moving forward. This is not
    > based on a hypothetical discussion or on a long term TODO list, this has
    > been determined from actually writing the code, which is located at:
    > So please, just because you don't want to acknowledge ConfigFS in your
    > own work, do not act like there is not already thounsands of lines of
    > ConfigFS code up and running for the generic target mode and LIO-Target.


    You have an *exceptional* ability don't see what you don't want to see.
    It has already happened with Persistent Reservations over pass-through
    backend (see the end of and
    subsequent messages in this thread) and now this is happening with
    configfs. I already 2 times described you why configfs isn't appropriate
    for a SCSI target (the first time in, but you keep refusing to see it.
    In short:

    1. Kernel can't create subdirectories in configfs

    2. Sysfs doesn't allow files >4K

    3. What you have been doing to live with the above limitations is
    implementing "access allowed only for explicitly specified initiators
    and forbidden for all others" security approach. This approach is
    unacceptable on practice. The majority of people simply define available
    devices for a target and don't bother with listing initiators, which
    allowed to connect to it. But you forces them to do that and keep doing
    again and again for each related network change.

    In contrast, sysfs allows kernel to create subdirectories. It will allow
    to workaround the 4K limitation by a simple subdirectories hierarchy.
    So, both security approaches ("access allowed only for explicitly
    specified initiators and forbidden for all others" and "access forbidden
    only for explicitly specified initiators and allowed for all others")
    can be seamlessly implemented on sysfs as it is currently done on procfs
    in SCST.


     \ /
      Last update: 2008-12-12 20:27    [W:0.023 / U:3.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site