From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Fri, 20 May 2005 22:07:23 +0000 Subject: Re: udev and sysfs permissions Message-Id: <1116626844.12975.122.camel@dhcp-188> List-Id: References: <9e47339105051915025188e535@mail.gmail.com> In-Reply-To: <9e47339105051915025188e535@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Fri, 2005-05-20 at 17:53 -0400, Jon Smirl wrote: > On 5/20/05, Greg KH wrote: > > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote: > > > On 5/20/05, Greg KH wrote: > > > > > That would make things simpler for driver writers if more devices are > > > > > going to follow this model. > > > > > > > > I think you are going to be pretty unique here, as no one else has come > > > > up with a situation yet that requires this. > > > > > > If the mantra about sysfs attributes being superior to IOCTLs is true, > > > then anyone who converts to sysfs attributes is going to run into this > > > problem. In the IOCTL model permission obviously follows the owner of > > > the /dev device. There is no parallel for this in the sysfs model. > > > > True. Hm, let me look into the sysfs code to see if we can just save > > the changed attributes, so that they do not get lost. That would be the > > simplest solution, right? > > That will work. Right now it is random for me from half an hour to > four hours before they get lost. That's the backing-store which holds the "real" information. If you read the attribute again after it is removed form the cache, you get the drivers state not the one in the vfs. Changes from userspace are not propagated into the sysfs attribute structures, but that shold be possible. Kay ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel