public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Deepak Saxena <dsaxena@plexity.net>
To: Dave Jones <davej@redhat.com>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	greg@kroah.com
Subject: Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs
Date: Wed, 11 Aug 2004 19:45:54 -0700	[thread overview]
Message-ID: <20040812024554.GA20792@plexity.net> (raw)
In-Reply-To: <20040811235929.GB32468@redhat.com>

On Aug 12 2004, at 00:59, Dave Jones was caught saying:
> 
> but why? it's totally pointless when the same info can be obtained
> from userspace without the bloat.
> 
<snip>
> 
> the raw binary is already available. in /dev/cpu/x/cpuid
> I repeat, duplicating this in sysfs is utterly pointless other than
> to bloat the kernels runtime memory usage.

I won't argue that there is no increase in memory usage. Looking at 
.text + .data for (i386/kernel/cpuid.c + i386/kernel/cpu/proc.c), there 
is a 2x increase (~1K -> ~2K) in size. I haven't looked at the runtime
memory required for extra the sysfs objects atm; however, given that sysfs 
is going to be used in just about every system out there (even small 
embedded devices), that size is probably negligble compared to the memory 
requirements for all the other users of sysfs. If we can look at
what really needs to be exported as a separate object and what
can be determined by userspace via parsing of binary blob, that
size diference will probably shrink considerably. 

>  > > /proc/cpuinfo has done well enough for us for quite a number of years
>  > > now, what makes it so urgent to kill it now that sysfs is the
>  > > virtual-fs-de-jour ?
>  > 
>  > Consitency in userspace interface.
> 
> sorry, but I think that argument is total crap.  Any userspace tool needing
> this info will still need to support the /dev/cpu/ interfaces if they want to
> also run on 2.2 / 2.4 kernels.  Likewise, anything using /proc/cpuinfo.
> Ripping this out does nothing useful that I see other than cause headache
> for userspace by having yet another interface to support.

In my original email I specifically said that we cannot remove /proc/cpuinfo 
today b/c of application requirements, but this is something for down
the road. The arbitrary date I choose (+1 year) can just as easilly be
+2 years to provide more time for apps to change over. Right now
there are 2 interfaces for cpu information via /proc/cpuinfo and /dev/cpu.
By moving to sysfs we can have 1 interface. That in itself seems like a
clear win.

>  > My understanding is that goal is to 
>  > make /proc slowly return to it's original purpose (process-information) 
>  > and move other data out into sysfs.  
> 
> I don't think thats a realistic goal. It'll take years just to migrate the
> in-kernel stuff, and there's god alone knows how much out-of-tree code doing
> the same, plus the add-ons from various vendor kernels etc so I doubt it'll
> ever be the process-only utopia you envision.

Nothing wrong with taking time. I never said we need to get rid of
stuff overnight. We can keep old interfaces around (see /proc/pci
for example) as long as it takes for core apps and kernel stuff
to switch over.

~Deepak

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

  reply	other threads:[~2004-08-12  2:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-11 22:41 [PATCH 0/3] Transition /proc/cpuinfo -> sysfs Deepak Saxena
2004-08-11 22:42 ` [PATCH 1/3] [Generic] " Deepak Saxena
2004-08-11 22:44 ` [PATCH 2/3] [i386] " Deepak Saxena
2004-08-11 22:47 ` [PATCH 3/3] [ARM] " Deepak Saxena
2004-08-11 22:47 ` [PATCH 0/3] " Deepak Saxena
2004-08-11 23:13 ` Dave Jones
2004-08-11 23:42   ` Deepak Saxena
2004-08-11 23:59     ` Dave Jones
2004-08-12  2:45       ` Deepak Saxena [this message]
2004-08-12 11:07         ` Dave Jones
2004-08-15  6:11       ` Andrew Morton
2004-08-15  6:33         ` Greg KH
2004-08-12  5:03 ` Lamont R. Peterson
2004-08-12 10:56   ` Dave Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040812024554.GA20792@plexity.net \
    --to=dsaxena@plexity.net \
    --cc=akpm@osdl.org \
    --cc=davej@redhat.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox