[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130218215434.GB16794@kroah.com>
Date: Mon, 18 Feb 2013 13:54:34 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Mauro Carvalho Chehab <mchehab@...hat.com>
Cc: balbi@...com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>, JBottomley@...allels.com,
linux-scsi@...r.kernel.org, davem@...emloft.net,
netdev@...r.kernel.org, Doug Thompson <dougthompson@...ssion.com>,
linux-edac@...r.kernel.org, rjw@...k.pl, linux-pm@...r.kernel.org
Subject: Re: SYSFS "errors"
On Mon, Feb 18, 2013 at 06:47:42PM -0300, Mauro Carvalho Chehab wrote:
> In the past, the sysfs node creation was done using the raw sysfs support.
> Doing dynamic creation with the old code were much more complex. I guess
> that's the reason why the code was written this way. Now that the code
> uses struct device, it shouldn't be hard to change the code to only
> create this attribute if the device has support for scrub rate setting.
>
> Yet, that would change the userspace API. I'm not sure what
> applications would rely on the current behavior. So, changing it
> would require some investigation in order to avoid regressions.
Because sysfs is "one value per file" the lack of a file showing up
shouldn't cause any userspace tools any problems, that is why we did
things this way.
But, of course, userspace programmers do know how to mess things up...
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists