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*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
