Messages in this thread | | | Date | Fri, 19 Aug 2005 20:33:37 -0700 | From | Greg KH <> | Subject | Re: [PATCH] Permissions don't stick on ConfigFS attributes |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |