On Mon, 27 Sep 2010 11:18:47 +0200 Michael Holzheu <holzheu@xxxxxxxxxxxxxxxxxx> wrote: > 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. That doesn't mean it was the right thing to do! For the reasons I outline above, it can be the wrong thing to do and strengthening one of the alternatives worsens the problem. > 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. Sounds like a big screwup ;) Look at it this way: if you were going to sit down and start to design a new operating system from scratch, would you design the task status reporting system as it currently stands in Linux? Don't think so! > 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. Maybe we should have delivered taskstats over procfs from day one. -- 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
