Hello Andrew, On Fri, 2010-09-24 at 11:50 -0700, Andrew Morton wrote: > > > This is a big change! If this is done right then we're heading in the > > > direction of deprecating the longstanding way in which userspace > > > observes the state of Linux processes and we're recommending that the > > > whole world migrate to taskstats. I think? > > > > Or it can be used as alternative. Since procfs has its drawbacks (e.g. > > performance) an alternative could be helpful. > > And it can be harmful. More kernel code to maintain and test, more > userspace code to develop, maintain, etc. Less user testing than if > there was a single interface. Sure, the value has to be big enough to justify the effort. But as I said, with taskstats and procfs we already have two interfaces for getting task information. Currently in procfs there is information than you can't find in taskstats. But also the other way round in the taskstats structure there is very useful information that you can't get under proc. E.g. the task delay times, IO accounting, etc. So currently tools have to use both interfaces to get all information, which is not optimal. > > > > > I worry that there's a dependency on CONFIG_NET? If so then that's a > > > big problem because in N years time, 99% of the world will be using > > > taskstats, but a few embedded losers will be stuck using (and having to > > > support) the old tools. > > > > Sure, but if we could add the /proc/taskstats approach, this dependency > > would not be there. > > So why do we need to present the same info over netlink? Good point. It is not really necessary. I started development using the netlink code. Therefore I first added the new command in the netlink code. I also thought, it would be a good idea to provide all netlink commands over the procfs interface to be consistent. > If the info is available via procfs then userspace code should use that > and not netlink, because that userspace code would also be applicable > to CONFIG_NET=n systems. > > > > > > Does this have the potential to save us from the CONFIG_NET=n problem? > > > > Yes > > Let's say that when it's all tested ;) That was more a theoretical statement :-) I probably still have to ensure that the kernel config options dependencies are done correctly. Michael -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
