[Devel] Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/

Serge E. Hallyn serue at us.ibm.com
Tue Jun 12 09:55:55 PDT 2007


Quoting Daniel Lezcano (dlezcano at fr.ibm.com):
> Carl-Daniel Hailfinger wrote:
> >On 11.06.2007 19:05, Serge E. Hallyn wrote:
> >>Quoting Cedric Le Goater (clg at fr.ibm.com):
> >>
> >>>should we continue to use /proc ? or switch to some other mechanisms
> >>>like getnetlink (taskstats) to map kernel structures.
> >>We want to avoid 'map'ping kernel structures, though, right?  We can
> >>dump the data in a more generic fashion through netlink, dunno what we
> >>prefer.  But this is very definately process information :), so /proc
> >>does seem appropriate.
> >
> >While I agree that /proc seems appropriate, I see a few benefits of
> >dumping the data through netlink:
> >* Speed. IIRC there were benchmarks showing an advantage of netlink
> >  over /proc when communicating with userspace. Sorry, no idea where
> >  I read that.
> >* Versioning. While we strive to have the perfect interface on the
> >  first try, changes might be necessary. I see no way to handle
> >  multiple versions of an interface in /proc without big headaches.
> >* Conformity. With /proc, people often see a file, take a look at
> >  it and try to infer the structure of the file from what they see.
> >  This has led to multiple problems in the past when the content of
> >  some files in /proc changed slightly and tools broke. With
> >  netlink, implementers have to look at the spec to achieve anything
> >  useful.
> 
> Right. And community seems to encourage to use the netlink and to stop 
> implementing new entry in /proc.
> 
> http://kerneltrap.org/node/6637

That's not quite what that thread is saying :)

For just this information, I would prefer /proc over netlink.  But since
we'll be dumping a whole bunch more data, I agree netlink may be the way
to go.

thanks,
-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list