Exactly, I fixed them; there is no difference.
> When possible, the device names need to be moved into the drivers
> that support the devices. The device names should be initdata so
> that the names for nonexistant devices can be deallocated.
> This saves memory, works for modules, and keeps _many_ people happy.
> Just not you perhaps.
Please explain: the information in /proc/pci is Text. It is unwise of
programmers to try and parse
Host bridge: Silicon Integrated Systems 85C496 (rev 49).
instead of
Class 0x600: Vendor id=0x1039, Device id=0x496 (rev 49).
The former is prone to typing errors. It would also be silly; the program
would have to "deformat" the string after all the trouble the kernel has
gone through. In any case, if the system is not known to the kernel (as
with new devices), you can not rely on the proper names.
The only reason for the /proc/pci format exists is that *humans* can
read them. There is really no reason that the number -> device name
translation be done in kernel space. Moving the strings out saves ~ 5k of
unpageable memory.
In your approach, how would the names be associated with the drivers? I
did not see references to pci_* functions in (eg) triton.c; Your
reasoning implies that all devices which are not kernel supported should
not have names in the kernel; from a user point of view this is equally
annoying compared to my approach.
> I think you broke some X servers too.
I tried running a PCI TGUI 9660 server with /proc unmounted; it worked OK.
Why would any portable program rely on /proc ?
> There really isn't much reason to do something annoying like this.
> The Linux kernel is not bloated at all. (see NT, Solaris...)
Yeah, and Solaris is not bloated when compared with VMS, Linux is
(probably) bloated when compared to QNX.
Your point?
> The kernel _should_ grow as time passes, because the extra features
> are nice to have. This is not a problem as long as the growth
> rate is well under the yearly 60% hardware performance increase.
And this bullshit, IMO. That is the same argument that Microsoft tries to
use when forcing new packages down users' throats. As far as i am
concerned the linux kernel should be as tight, clean and fast possible
given the resources. That makes many people happy, not just you.
But I will look into what another suggested, the linux configuration
manager, and the 2.1.x series:
> There is the Linux Kernel Configuration Manager
> <http://zen.btc.uwe.ac.uk/linux/cmgr/> which is intended to solve a larger
> problem, but it is also a larger chunk of source.