public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Deepak Saxena <dsaxena@plexity.net>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	greg@kroah.com
Subject: Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs
Date: Thu, 12 Aug 2004 12:07:29 +0100	[thread overview]
Message-ID: <20040812110729.GP17673@redhat.com> (raw)
In-Reply-To: <20040812024554.GA20792@plexity.net>

On Wed, Aug 11, 2004 at 07:45:54PM -0700, Deepak Saxena wrote:

 > 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. 

And if we decide not to do this, the size difference shrinks even
more considerably. People who don't give a rats ass about this stuff
aren't wasting memory for each sysfs node.

The only justification I've seen so far for this bloat is
"other subsystems have put their crap in sysfs, so I want to do the same".

 > >  > > /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.

Yes. And then when presented with the "but this is useless, because we already
have /dev/cpu" argument, you decided to deprecate that for no reason too,
in the name of 'consistency'.

This is madness.

This 'consistency' costs. As I already mentioned, an application that
runs on any kernel would now have to support an extra method of obtaining
the data it needs.  Then people wonder why userspace apps are bloating
up further and further each year. Then people wonder why installers
suddenly need an extra xMB of RAM to install the latest version of
a distro.

 > 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.

There was a 'joke' a while ago about some corporations handing out
bonuses to its engineers each time a patch was accepted that removed
a user of the big kernel lock.  These days I wonder if the same
analogy is holding true for systfs patches.

		Dave


  reply	other threads:[~2004-08-12 11:09 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
2004-08-12 11:07         ` Dave Jones [this message]
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=20040812110729.GP17673@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@osdl.org \
    --cc=dsaxena@plexity.net \
    --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