Re: [PATCH] Permissions don't stick on ConfigFS attributes

[Greg KH]

On Sat, Aug 20, 2005 at 01:23:29PM +1000, Daniel Phillips wrote:
> On Saturday 20 August 2005 13:01, Greg KH wrote:
> > On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
> > > So: Integrate with sysfs.
> >
> > No, don't.  Do you think that Joel would not have already worked with
> > the sysfs people prior to submitting this?  No, he did, and we all
> > agreed that it should be kept separate.
> 
> Would you care to recap the reasoning, please?

They do two different things, and people interact with them in two
different ways.  So, they should be two different file systems.

> > > Terminology skew.  It is a very bad idea to call your configfs files
> > > "attributes".
> >
> > That's what sysfs calls its files.  They used the same naming scheme
> > there.  This is nothing that a user ever cares about or sees.
> 
> It's wrrrrronnnggg.  The best you can defend this with is "it's entrenched".

Will a user ever see the word "attribute"?  Also, these files represent
attributes of the main object in which they are attached to.  Hence the
name.

> > > Memory requirements.  ConfigFS pins way too much kernel memory for inodes
> > > and dentries.
> >
> > configfs is not going to have that many nodes at all in memory (compared
> > to sysfs), so I don't think this is a big problem.
> 
> The current bloat is unconscionable, for the amount of data that is carried.  
> Are you arguing against fixing it?  And what makes you think configfs will 
> never have lots of nodes?

Doesn't it currently work the same way as sysfs with the backing store
being created on the fly?  If not, it should be pretty simple to convert
over if people are really worried about memory consumption, but again,
why don't we see how many nodes are really used on most systems (don't
want to add more complexity and kernel code if you never really need
it.)

thanks,

greg k-h
-
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/