[PATCH 0/2] Allow access to sysfs attributes without mem allocations.

[NeilBrown]

Hi Tejun,
 is this closer to what you would like?

 I do really need this functionality, but I honestly don't like this
 patch.
 The need to identify just which attributes need special care seems
 backwards to me.
  1/ it is the process (which has called mlock etc) which needs
     special care, more than the attribute.  Everything that process
     does needs to avoid allocating memory, whether that this is
     particularly related to enabling write-out or not.
  2/ It is also backwards because the vast majority of sysfs
     attributes only support bool/enum/int which means at most
     23 chars including sign and newline (maybe more for reads if the
     read provides a list of options).  So almost everything
     doesn't need an allocation at all - just some on-stack space.
     I would be quite happy to identify those attributes that
     may need care when accessing and could possibly supports
     read or write > 128 characters, because there wouldn't be any.

  I also don't like this approach because we end up allocating 2 pages
  for the buffer, as we have to ask for "PAGE_SIZE+1" bytes, for the
  hypothetical case that an important attribute actually requires a
  full PAGE_SIZE write...

  Would you be happy to have all specially identified attributes be
  limited to 127 characters IO max?  Then I would just use an on-stack
  buffer for those which would remove the allocation and simplify some
  of the code.

Thanks,
NeilBrown

---

NeilBrown (2):
      sysfs - allow attributes to request write buffer be pre-allocated.
      sysfs/kernfs: make read requests on pre-alloc files use the buffer.


 fs/kernfs/file.c       |   52 +++++++++++++++++++++++++++++++----------------
 fs/sysfs/file.c        |   53 +++++++++++++++++++++++++++++++++++++++++-------
 include/linux/kernfs.h |    2 ++
 include/linux/sysfs.h  |    9 ++++++++
 4 files changed, 90 insertions(+), 26 deletions(-)

-- 
Signature

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