Hello,
Linux-2.6.15.4 fails to contain the file:
/usr/src/linux-2.6.15.4/drivers/pci/devlist.h
This contains product NAMES used to identity various PCI
devices when they are installed. What replaces this file?
The file existed up until at least linux-2.6.13.4 and
should not have been removed just because some audit
may have determined that it's "not in use." It is in
use by vendors which need to convert "Computerese" to
"Customer readable" stuff.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.49 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Mon, 2006-02-20 at 12:08 -0500, linux-os (Dick Johnson) wrote:
>
> Hello,
> Linux-2.6.15.4 fails to contain the file:
> /usr/src/linux-2.6.15.4/drivers/pci/devlist.h
>
> This contains product NAMES used to identity various PCI
> devices when they are installed. What replaces this file?
>
> The file existed up until at least linux-2.6.13.4 and
> should not have been removed just because some audit
> may have determined that it's "not in use." It is in
> use by vendors which need to convert "Computerese" to
> "Customer readable" stuff.
actually an entirely different file is used for that;
/usr/share/hwdata/pci.ids
which comes from the pci id repo on sourceforge (same as the file you
want to look at). Distributions at least tend to update pci.ids file
more frequent than the kernel updated devlist.h...
On Mon, 20 Feb 2006, Arjan van de Ven wrote:
> On Mon, 2006-02-20 at 12:08 -0500, linux-os (Dick Johnson) wrote:
>>
>> Hello,
>> Linux-2.6.15.4 fails to contain the file:
>> /usr/src/linux-2.6.15.4/drivers/pci/devlist.h
>>
>> This contains product NAMES used to identity various PCI
>> devices when they are installed. What replaces this file?
>>
>> The file existed up until at least linux-2.6.13.4 and
>> should not have been removed just because some audit
>> may have determined that it's "not in use." It is in
>> use by vendors which need to convert "Computerese" to
>> "Customer readable" stuff.
>
>
> actually an entirely different file is used for that;
> /usr/share/hwdata/pci.ids
>
> which comes from the pci id repo on sourceforge (same as the file you
> want to look at). Distributions at least tend to update pci.ids file
> more frequent than the kernel updated devlist.h...
Thanks. Changes like that make tons of work! Great, there will
always be something for us to do. Now all I have to do is
modify a tool to be Linux version-specific so I get the right
ASCII put into driver(s). The drivers don't run in anything
that has a shell or anything like that. They need to "know"
the vendor-name of some interface chips so the name(s) were
compiled in, based upon OS headers.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.49 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Mon, 20 Feb 2006, linux-os (Dick Johnson) wrote:
> On Mon, 20 Feb 2006, Arjan van de Ven wrote:
>
> > On Mon, 2006-02-20 at 12:08 -0500, linux-os (Dick Johnson) wrote:
> >>
> >> Hello,
> >> Linux-2.6.15.4 fails to contain the file:
> >> /usr/src/linux-2.6.15.4/drivers/pci/devlist.h
> >>
> >> This contains product NAMES used to identity various PCI
> >> devices when they are installed. What replaces this file?
> >>
> >> The file existed up until at least linux-2.6.13.4 and
> >> should not have been removed just because some audit
> >> may have determined that it's "not in use." It is in
> >> use by vendors which need to convert "Computerese" to
> >> "Customer readable" stuff.
> >
> >
> > actually an entirely different file is used for that;
> > /usr/share/hwdata/pci.ids
> >
> > which comes from the pci id repo on sourceforge (same as the file you
> > want to look at). Distributions at least tend to update pci.ids file
> > more frequent than the kernel updated devlist.h...
>
> Thanks. Changes like that make tons of work! Great, there will
> always be something for us to do. Now all I have to do is
> modify a tool to be Linux version-specific so I get the right
> ASCII put into driver(s). The drivers don't run in anything
> that has a shell or anything like that. They need to "know"
> the vendor-name of some interface chips so the name(s) were
> compiled in, based upon OS headers.
If you actually want a "devlist.h" file, 2.6.11 has a program
gen-devlist.c that generates it (and "classlist.h") from pci.ids. The
kernel source hasn't come with a devlist.h file since before the dawn of
time (i.e., the beginning of the git repository). The only recent change
is not including a pci.ids or generating a devlist.h from it.
-Daniel
*This .sig left intentionally blank*
On Mon, 20 Feb 2006, Daniel Barkalow wrote:
> On Mon, 20 Feb 2006, linux-os (Dick Johnson) wrote:
>
>> On Mon, 20 Feb 2006, Arjan van de Ven wrote:
>>
>>> On Mon, 2006-02-20 at 12:08 -0500, linux-os (Dick Johnson) wrote:
>>>>
>>>> Hello,
>>>> Linux-2.6.15.4 fails to contain the file:
>>>> /usr/src/linux-2.6.15.4/drivers/pci/devlist.h
>>>>
>>>> This contains product NAMES used to identity various PCI
>>>> devices when they are installed. What replaces this file?
>>>>
>>>> The file existed up until at least linux-2.6.13.4 and
>>>> should not have been removed just because some audit
>>>> may have determined that it's "not in use." It is in
>>>> use by vendors which need to convert "Computerese" to
>>>> "Customer readable" stuff.
>>>
>>> actually an entirely different file is used for that;
>>> /usr/share/hwdata/pci.ids
>>>
>>> which comes from the pci id repo on sourceforge (same as the file you
>>> want to look at). Distributions at least tend to update pci.ids file
>>> more frequent than the kernel updated devlist.h...
>>
>> Thanks. Changes like that make tons of work! Great, there will
>> always be something for us to do. Now all I have to do is
>> modify a tool to be Linux version-specific so I get the right
>> ASCII put into driver(s). The drivers don't run in anything
>> that has a shell or anything like that. They need to "know"
>> the vendor-name of some interface chips so the name(s) were
>> compiled in, based upon OS headers.
>
> If you actually want a "devlist.h" file, 2.6.11 has a program
> gen-devlist.c that generates it (and "classlist.h") from pci.ids. The
> kernel source hasn't come with a devlist.h file since before the dawn of
> time (i.e., the beginning of the git repository). The only recent change
> is not including a pci.ids or generating a devlist.h from it.
>
> -Daniel
The modules were generally compiled against a compiled kernel that
has everything we need enabled, including PCI -- and what
we don't use, disabled. So, the file was available up until
2.6.13.4 and disappeared by 2.6.15.4. Also, even the pci.ids
has now been eliminated. This means that one needs to keep
/usr/share/hwdata/pci.ids current if that is what we need to
use now, which implies that one needs a specific Linux
distribution NotGood(tm).
The major problem, not completely understood by many, is
that when a customer says they need to know the vendor name(s)
of the devices on a particular board, by making an ioctl() call
to the device-driver, we cannot say; "Use a user-mode program."
We need to provide what the customer required. During the lifetime
of the product, we cannot change the requirements because that
would require a new certification from a federal agency, either
FAA/TSA for security stuff, or FDA for medical stuff. So, when
stuff gets removed from the kernel, it shouldn't be arbitrary.
There should be some kind of notice that something is going
away so that people who make embedded systems, that don't have
any ability to "use another program", can accommodate.
Most embedded systems do not have any 'init', shells, or
anything like that. That's what makes them reliable and
secure. The only thing that could possibly get executed
is what designers designed and coded for the system. So
moving something that has been "in the kernel" to "outside"
has some considerable consequences, especially since there
isn't an "outside".
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.49 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, 21 Feb 2006, linux-os (Dick Johnson) wrote:
> The modules were generally compiled against a compiled kernel that
> has everything we need enabled, including PCI -- and what
> we don't use, disabled. So, the file was available up until
> 2.6.13.4 and disappeared by 2.6.15.4. Also, even the pci.ids
> has now been eliminated. This means that one needs to keep
> /usr/share/hwdata/pci.ids current if that is what we need to
> use now, which implies that one needs a specific Linux
> distribution NotGood(tm).
You could just include the latest pci.ids in your module, which wouldn't
be any worse than relying on the kernel to have an up-to-date one. For
that matter, if they're building the latest version of your code against
an old kernel, the pci.ids in the old kernel is obviously going to be at
least as old as the kernel, if not older. Most likely, the most current
files around when someone is building your code will be your code, so, if
it includes a pci.ids, chances are that it's the best one to use. I
generally haven't seen the file get installed; most packages seem to just
include a copy if they need it.
> Most embedded systems do not have any 'init', shells, or
> anything like that. That's what makes them reliable and
> secure. The only thing that could possibly get executed
> is what designers designed and coded for the system. So
> moving something that has been "in the kernel" to "outside"
> has some considerable consequences, especially since there
> isn't an "outside".
I'm actually more used to embedded systems that don't have any way of
communicating a string to the user. Or having unexpected PCI devices
plugged into them.
Doing stuff in the kernel instead of userspace doesn't make the system any
more secure or reliable, either. They'd probably be better off having
their display code use libpci, so that, if the translation screws up, some
non-critical userspace program aborts instead of the kernel oopsing or
panicing. You don't need a shell to use a library.
-Daniel
*This .sig left intentionally blank*