All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Ball <cjb@laptop.org>
To: Muthu Kumar <muthu.lkml@gmail.com>
Cc: merez@codeaurora.org, linux-mmc@vger.kernel.org,
	linux-arm-msm@vger.kernel.org,
	DOCUMENTATION <linux-doc@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] mmc: block: Add write packing control
Date: Sat, 14 Jul 2012 15:12:54 -0400	[thread overview]
Message-ID: <87629qkvgp.fsf@octavius.laptop.org> (raw)
In-Reply-To: <CAFR8ueecGqw=JzAGVHV61-SqOnn_C-ryT54KCQCbKkJpXUGY9w@mail.gmail.com> (Muthu Kumar's message of "Wed, 13 Jun 2012 15:21:49 -0700")

Hi,

On Wed, Jun 13 2012, Muthu Kumar wrote:
> On Wed, Jun 13, 2012 at 12:52 PM,  <merez@codeaurora.org> wrote:
>>
>> On Mon, June 11, 2012 5:28 pm, Muthu Kumar wrote:
>>> On Mon, Jun 11, 2012 at 2:19 PM, Muthu Kumar <muthu.lkml@gmail.com> wrote:
>>>> On Fri, Jun 1, 2012 at 11:55 AM, Maya Erez <merez@codeaurora.org> wrote:
>>>>> trigger
>>>>> the packing can be configured via sysfs by writing the required value
>>>>> to:
>>>>> /sys/block/<block_dev_name>/num_wr_reqs_to_start_packing.
>>>>> The trigger for disabling the write packing is fetching a read request.
>>>>>
>>>>
>>>> If it is applicable only to MMC why do we have this sysfs attr for all
>>>> block devices?
>>>
>>> Just to be clear, please create a directory, say mmc, under
>>> /sys/block/<dev>/ and create the attr inside that.
>>>
>>> You can refer to dm (dm-sysfs.c) for sample implementation.
>> I understand why you think it would be best to distinguish the MMC
>> specific attribute from the general block devices attributes.
>> However, since this attribute is created only for the MMC block device,
>> other block devices won't be aware of it.
>
> I understand its created by the MMC code so will not be there for
> other block devices. But having the device specific attributes inside
> one <device> directory is better/cleaner. And since we are already
> following that model for other devices, why not follow that for MMC
> also?

I've already replied to a later version of the patch, but just to get
this comment in at the appropriate point of the discussion as well:

Even though it would result in a cleaner sysfs, I don't want to do
this now because it will break userspace scripts that are depending
on the current locations of these attributes.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

  parent reply	other threads:[~2012-07-14 19:13 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-01 18:55 [PATCH v2 0/1] mmc: block: Add write packing control Maya Erez
2012-06-01 18:55 ` [PATCH v2 1/1] " Maya Erez
2012-06-01 18:55   ` Maya Erez
2012-06-08  9:37   ` Seungwon Jeon
2012-06-09 14:46     ` merez
2012-06-11  9:10       ` Seungwon Jeon
2012-06-11 13:55         ` merez
2012-06-11 14:39           ` S, Venkatraman
2012-06-11 20:10             ` merez
2012-06-12  4:16               ` S, Venkatraman
2012-06-11 17:19       ` S, Venkatraman
2012-06-11 20:19         ` merez
2012-06-12  4:07           ` S, Venkatraman
2012-06-11 21:19   ` Muthu Kumar
2012-06-12  0:28     ` Muthu Kumar
2012-06-12 20:08       ` merez
2012-06-13 19:52       ` merez
2012-06-13 22:21         ` Muthu Kumar
2012-06-14  7:46           ` merez
2012-07-14 19:12           ` Chris Ball [this message]
2012-07-16  1:49             ` Muthu Kumar
2012-07-16  2:46               ` Chris Ball
2012-07-16 16:44                 ` Muthu Kumar
2012-07-17 22:50                   ` Chris Ball
2012-07-18  6:34                     ` merez
2012-07-18  7:26                       ` Chris Ball
2012-07-18  7:26                         ` Chris Ball
2012-07-19  0:33                     ` Muthu Kumar
2012-07-17  4:15                 ` S, Venkatraman
  -- strict thread matches above, loose matches on Subject: below --
2012-06-12 19:05 merez
2012-07-23 11:43 merez
2012-07-23 11:43 ` merez
2012-07-23 12:22 ` S, Venkatraman
2012-07-24  8:44 merez
2012-07-24 20:23 ` merez
2012-07-24 20:23   ` merez
2012-07-24 20:52   ` merez
2012-07-24 20:52     ` merez
2012-07-26 15:28 ` S, Venkatraman
2012-07-26 18:54   ` merez
2012-07-27  9:07     ` S, Venkatraman
2012-08-27 18:28       ` merez
2012-08-28 17:40         ` S, Venkatraman
2012-09-06  5:17           ` merez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87629qkvgp.fsf@octavius.laptop.org \
    --to=cjb@laptop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=merez@codeaurora.org \
    --cc=muthu.lkml@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.