>> I thought the idea was to remove that functionality out of the
>> kernel completely. In our case, we're only adding the "names"
>> for the cards that "our" driver supports. We have a 16 or
>> 20-byte structure per card already, and if we want, we can
>> declare it all to be init_data.
>> Anyway, if you don't like the strings-in-the-table approach, we
>> should move to an exported function from oldproc which returns
>> the name of a PCI device.
> It's not that I don't like the strings-in-the-table approach as
> much as I don't like the idea of strings-in-two-tables approach.
> If we have a PCI number->string database in oldproc, keeping a
> separate databases in the serial driver just seems like a bad
> idea, besides potentially wasting space.
> As far as the approach of declaring the pci table to be
> init_data, that may work for now, but it won't work in the long
> run once we support hot-pluggable PCI. (I currently use
> register_serial() to register individual PCI serial ports.
> This wasn't an accident, since I was thinking about hot
> pluggable PCI support in the future.)
It sounds like such would be best defined as only being available as a
module, similar to the ppp compression modules, and only available if
module support is enabled AND an option to use the said module is also
enabled.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/Linux/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/