Re: /proc/pci design idea

thospel@mail.dma.be
15 Sep 1997 21:51:01 -0000


In article <199709150644.IAA23642@lrc.di.epfl.ch>,
"Werner Almesberger" <almesber@lrc.di.epfl.ch> writes:
> Stephen Williams wrote:
>> Each of the files there is the configuration space for the device with the
>> given bus/slot number.
>
> Hmm, if it's two digits for each, maybe a separator should be between
> them so that people don't think this is a single 16 bit space.
>
>> then will start in on the usr mode program that does the pretty printing.
>
> One suggestion: it would be nice to have the actual translation data in a
> directory with plain text files (/lib/pci ?). This way, packages with new
> drivers can add the names cleanly without needing to "upgrade" the pretty
> printer executable.
>
> Someone complained about the files being binary. An idea just crossed my
> mind: you could make the files executable and add a new executable format
> handler for the pretty printer.
>
> - Werner
>

Another possibility is to have /proc/pci handled by a module, that in itself
knows nothing but on load gets it's database from a userspace program that reads
it from a file. Then it constructs /proc/pci in the normal way.

In that case the people who want a readable proc are happy, and we only waste
the kernel memory as long as the module is loaded. And the people who don't
even want that can feed the module an empty database, and the module would fall
back to printing some hex numbers where a user space program can pick them up
and translate them

Or if the thing is not compiled as a module, you would still need the
userspace program to feed the kernel a pci database. In that case you don't
gain memory, but it still saves you in the size of your image.
And if you don't feed it data, you DO gain the memory and the userspace
program can again extract the data

(or you could feed it only the devices you KNOW you have, or do clever things
like write a program that checks in userspace what's there, and only feed
that into the kernel etc.)

Ton
.