All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maneesh Soni <maneesh@in.ibm.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev and sysfs permissions
Date: Fri, 27 May 2005 12:44:28 +0000	[thread overview]
Message-ID: <20050527123228.GA9959@in.ibm.com> (raw)
In-Reply-To: <9e47339105051915025188e535@mail.gmail.com>

On Thu, May 26, 2005 at 04:09:51PM -0700, Greg KH wrote:
> On Sat, May 21, 2005 at 12:07:23AM +0200, Kay Sievers wrote:
> > On Fri, 2005-05-20 at 17:53 -0400, Jon Smirl wrote:
> > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > > > > On 5/20/05, Greg KH <greg@kroah.com> 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?
> 
> Ugh, in trying to figure this out for the past few days, I've gotten no
> where at all :(
> 
> Maneesh, any chance we could get some help?  The issue is, if a user
> changes the owner:group or permissions on a sysfs file, it would be nice
> to have those changes stay.  Due to the backing-store changes, over
> time, the sysfs files are re-created, and those user-made changes are
> lost.  I've poked around in sysfs, and tried to add some new functions
> for the vfs to call when an inode is dirty, but had no luck at all in
> getting this to work.  Any ideas?
> 

It should be doable. But again this will increase the size of sysfs_dirent 
structure. If I am not wrong we will need to save (persistent) struct iattr 
for each sysfs_dirent there by increasing its size by 52 bytes on i386 and
we will need ->i_op->setattr() and ->i_op->getattr() routines for sysfs. 

Do we need this functionality in all sysfs objects or only for certain type
of sysfs objects?

Maneesh

-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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

  parent reply	other threads:[~2005-05-27 12:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19 22:02 udev and sysfs permissions Jon Smirl
2005-05-19 22:10 ` Kay Sievers
2005-05-20  4:33 ` Greg KH
2005-05-20 14:06 ` Jon Smirl
2005-05-20 18:33 ` Greg KH
2005-05-20 21:11 ` Jon Smirl
2005-05-20 21:26 ` Jon Smirl
2005-05-20 21:27 ` Greg KH
2005-05-20 21:40 ` Jon Smirl
2005-05-20 21:40 ` Greg KH
2005-05-20 21:41 ` Jon Smirl
2005-05-20 21:53 ` Jon Smirl
2005-05-20 21:54 ` Greg KH
2005-05-20 21:56 ` Greg KH
2005-05-20 22:07 ` Kay Sievers
2005-05-20 22:09 ` Greg KH
2005-05-26 23:09 ` Greg KH
2005-05-27 12:44 ` Maneesh Soni [this message]
2005-05-27 16:39 ` Jon Smirl
2005-05-27 21:51 ` Greg KH
2005-05-28  5:06 ` maneesh
2005-05-28  5:08 ` maneesh

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=20050527123228.GA9959@in.ibm.com \
    --to=maneesh@in.ibm.com \
    --cc=linux-hotplug@vger.kernel.org \
    /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.