Re: [PATCH RFC] btrfs: introduce procfs interface for the device list

[Duncan <1i5t5.duncan@cox.net>]

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