[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