Messages in this thread | | | Date | Thu, 24 Oct 2002 17:40:12 -0400 | From | Jeff Garzik <> | Subject | Re: Switching from IOCTLs to a RAMFS |
| |
Patrick Mochel wrote:
> On Thu, 24 Oct 2002, Jeff Garzik wrote: > >> Mark Peloquin wrote: >> >>> Based on the feedback and comments regarding >>> the use of IOCTLs in EVMS, we are switching to >>> the more preferred method of using a ram based >>> fs. Since we are going through this effort, I >>> would like to get it right now, rather than >>> having to switch to another ramfs system later >>> on. The question I have is: should we roll our >>> own fs, (a.k.a. evmsfs) or should we use sysfs >>> for this purpose? My initial thoughts are that >>> sysfs should be used. However, recent discussions >>> about device mapper have suggested a custom ramfs. >>> Which is the *best* choice? >> >> >> (cc'd viro and mochel, as I feel they are 'owners' in the subject area) >> >> Let's jump back a bit, for a second. Why is procfs bad news? There are >> minor issues with the implementation of single-page output and lack of >> pure file operations, but the big issue is lack of a sane namespace. >> sysfs is no better than procfs if we keep heaving junk into it without >> thinking about proper namespace organization. > > > That's one of my personal goals: to mandate some amount of sanity in the > namespace organization. Without it, sysfs is basically just a modernized > procfs.
Is there a namespace doc or guideline we can look at? (for existing nodes, sure, but more guidelines for future nodes)
> >> I personally prefer a separate filesystem for what you describe. That >> gives the EVMS team control over their own portion of the namespace, >> while giving complete flexibility. I do _not_ see sysfs as simply a >> procfs replacement -- sysfs IMO is more intended as a way to organize >> certain events and export internal kernel structure. > > > I do not view those as necessarily competing goals. The mission statement > of sysfs is to "export kernel objects, their attributes, and their > relation to other objects". > > EVMS, like any other subsystem, has a set of objects and methods to > operate on them, as exported via attributes. They have their have their > own object hierarchy, and in no way do I want to dilute that (or pollute > anything else ;). sysfs should be able to handle this. It does today, > though it's not as seamless as I would prefer it.
I hope that sysfs imposes some sort of structure on random sysfs users?
> > I would rather mature the API and consolidate the common code, than > have N > copies of the same filesystem, each with a slightly different purpose, in > existence. There are so many benefits: > > - Less code duplication, and less places to fix identical bugs.
Not in this argument :) libfs.c handles this quite nicely. And it's just a matter of moving more code into libfs.c for things like this.
In fact it looks like some of the sysfs/inode.c code could be moved to libfs.c or should be using libfs.c code ;-)
Further, looking at current sysfs/inode.c code, it seems that ->read and ->write ops provided are severely lacking in flexibility. If you let users provide their own file_operations directly, that would be nice. Calling __get_free_page and having users send data to that page is easy -- and kills quite a lot of flexibility that would push one towards creating a private 'meta' filesystem. Having that page provided for you is IMO really only useful for spitting out status data...
> > - It makes it easier to write for; instead of having to copy n' paste a > new filesystem to export your subsystem's objects, you can add a field > to a structure and call a function.
This is a function of any API. copy-n-paste is not an argument against a private filesystem -- see libfs.c counter-argument above.
> - It's easier for the user to mount one filesystem and get everything, > instead of trying to figure out what fs has what ifno.
agreed
> - It's easier to associate objects between subsystems, since you can > internally create relative symlinks between two objects (and soon with a > single call).
agreed
So let users provide their own file_operations, and have guidelines for new users, and I'll be happier :)
Jeff
- 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/
| |