Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

• Previous message: Adrian Bunk: "[2.6 patch] small Kconfig corrections for two ATARI net drivers"
• In reply to: Deepak Saxena: "Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs"
• Next in thread: Andrew Morton: "Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Thu, 12 Aug 2004 12:07:29 +0100
To: Deepak Saxena <dsaxena@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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

• Previous message: Adrian Bunk: "[2.6 patch] small Kconfig corrections for two ATARI net drivers"
• In reply to: Deepak Saxena: "Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs"
• Next in thread: Andrew Morton: "Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]