>>> [proposed removal of /proc/pci]
>> Grrr... don't you even think of it!
>>
>> People paid money for those servers. How does /proc/pci hurt you?
>> If you don't like it, you have the config option. Maybe there should
>> never have been a /proc/pci, but it's there now and I'm addicted to it.
>>
>> One common complaint about Linux is that is changes too often.
>> This wouldn't be just a new version freaking out a PHB, but a real
>> incompatible change. It's not even a change we need for standards
>> compliance. If /proc/pci somehow impedes development, please explain.
>
> If cruft is kept, purely for the sake of backwards compatibility, when
That "purely for the sake of backwards compatibility" hints at an
attitude problem. Is backwards compatibility unimportant to you?
You sound like a glibc developer...
> better alternatives exist, then it leads to maintenance nightmares.
That does not compute.
1. feature X exists for backwards compatibility
2. better alternatives exist
3. therefore, feature X is a maintenance nightmare
Are you saying it was always a maintenance nightmare, or that it
suddenly becomes one when you have something better?
> If you need a feature of an older kernel to run your proprietary
> software then use an older kernel. There's no reason that newer
> kernels must be forced to implement out of date or buggy features.
It is nice that you have no personal need for /proc/pci.
> /proc/pci is a mistake because it requires a kernel change everytime a
> new piece of PCI hardware is released.
The kernel generally needs a new driver anyway, the change required
isn't something that requires serious hacking effort, and it isn't
a tragedy when something new isn't listed.
> The new /proc/bus scheme places
> the name/number database into user space where it belongs and where it
> can be updated more frequently, or even accessed directly by apps that
> have a better database than the free pciutils one.
Fine, we can have both.
As if it mattered, the kernel is much easier to update than userspace.
Linus is normally quite good about backwards compatibility, so I don't
need to worry much about things breaking. 2.1.xxx only messed up some of
the system-specific network software for me. Userspace is another matter.
Userspace has a complex web of library dependencies.
> Always remember that if the feature is really necessary, then often it
> is maintained outside the kernel, usually as a loadable module or as a
> patch against the kernel. Removing it from the mainstream kernel won't
> hurt you, and will encourage user space applications (be they free or
> proprietary) to update their interfaces.
Leaving it in won't hurt you, and will encourage people to trust Linux.
Most OS companies keep things that _do_ hurt them, while you want to
throw out some harmless source code bloat. This makes no sense.
In case you missed the sound and UID threads: some people lost their
source code and don't want to write new code just yet. Many people
want to run obsolete commercial software. Whatever the reason, you
can't just toss out the old interfaces.
Let's ask David Parsons. He runs libc 4 BTW.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/