David Mosberger <mailto:[EMAIL PROTECTED]> wrote on Thursday, February 24, 2005 5:27 PM:
>>>>>> On Tue, 22 Feb 2005 10:24:40 -0800, "Seth, Rohit" >>>>>> <[EMAIL PROTECTED]> said: > > Rohit> I agree that the format of these fields should match the > Rohit> format of other fields in cpuinfo.....though it will be nice > Rohit> if we have the same format as that of i386 cpuinfo output. > > I'm not sure there is much point to that: > > (a) The contents of /proc/cpuinfo is by definition > architecture-specific > No arguments there. > (b) Applications _should_ allow any whitespace when parsing > /proc/cpuinfo, so in properly-written applications, it shouldn't > matter whether whitespace or tabs are used. > > Changing the formatting of /proc/cpuinfo only runs the risk of > existing tools, without benefit to properly written applications. > I hope there are not that many apps that have this behavior...particularly if they are (/want to be) portable. In any case, I will have this changed (tabs replaced with white space) in next rev of this patch. > Rohit> I was thinking of this information as something that apps can > Rohit> use to find the information about which logical execution > Rohit> units (leu) are threads on the same core, which leu are on > Rohit> the same package and so on. This is similar to i386(HT > Rohit> enabled processors) where siblings gives the number of > Rohit> threads on the same package. > > I'm not a fan of including redudant info in /proc files. > I think we should have some consistency (wherever possible) in /proc/cpuinfo fields across architectures. This will help applications writers. Currently siblings and cpu core fields are already added for i386 and x86_64. Thoughts? > Rohit> Typically the field names in various PAL call related data > Rohit> structures match their definition in SDM.... > > I don't think we need to constrain ourselves too much to what the PAL > names are. That code is part of the kernel and it should be readable. > I probably should send you a bigger PAL field cleanup patch first ;-) - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
