Chris Mason posted on Wed, 01 Oct 2014 10:09:12 -0400 as excerpted: >>> We're going to have a really hard time getting a new proc interface >>> merged in, and after we've recently fixed up all (most?) of our sysfs >>> races, I'd rather not have to do it all over again with /proc. >> >> This does not use fsid/devid based file-directory. So races as were in >> sysfs implementation does not apply here. (But there are >> opportunity >> to optimize the code at the place mentioned in the code as todo). > > Right, proc has different races ;) Again the bar for new interfaces in > proc is really very high. It's not the direction the rest of the kernel > is using.
Put differently... Proc has fallen out of favor as an early experiment in virtual filesystem kernel interfaces that ran amok due to lack of governing rules at the time and is effectively legacy/deprecated. From this viewpoint the most simple explanation for its continued existence is Linus' "prime directive" that you don't break userspace -- being the primary/only kernel/userspace virtual filesystem interface for quite some time, there's a *LOT* of stuff that depends on proc, and despite what many might want, it's not going to disappear overnight. That's the kind of resistance you're looking at to get something new in proc. Basically, it's not going to happen. So as Chris recommends, go tilt at a different windmill. Getting this one to move is going to require moving heaven and hell both, and it's just not worth it. Sys does have stricter rules, but they are there for a reason, to ensure the mistakes that were made with proc don't get made with sys as well. That's the accepted place to put stuff that might have, in an earlier time, gone into proc, but now following the rules for sys, of course. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
