Messages in this thread | | | Date | Mon, 10 Nov 1997 10:35:57 +0100 (MET) | From | Han-Wen Nienhuys <> | Subject | PCI Strings in Userspace? (yes!) |
| |
On Sat, 8 Nov 1997 owner-linux-kernel-digest@vger.rutgers.edu wrote: > > I read someone complaining about having the PCI-device names in > > kernel-space. I thought this would be an easy thing to fix. > > You didn't fix the names, you removed them. Big difference!
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.
Han-Wen Nienhuys, hanwen@stack.nl | LilyPond - The GNU Project music typesetter http://www.stack.nl/~hanwen | http://www.stack.nl/~hanwen/lilypond/
| |