I think this is pretty much what I'm in the middle of doing. I want to put the infrastructure in place so that we can handle an arbitrary PCI device but I will only put the actual code in to handle the PCI card that I have (the only one I can test).
What I'm doing is creating a table that matches the tuple (vendor id, device id, subsystem vendor id, subsystem device id, device type, device type mask) to a base baud and a configuration function. The default configuration function does nothing so the table only provides the base baud. We can add config functions for different cards as time goes by. The user can always specify a specific I/O port and base baud for his/her specific device, the table is really just a heuristic to provide a reasonable default that can always be over-ridden. Note that what I'm doing will make the serial module dependent upon the pci module but I don't see that that's a big concern. Pretty much any modern machine will have a PCI bus so scanning it should not be a problem. Also, note that the legacy serial devices (I/O ports at 0x3f8 & 0x2f8) are going away, in the not too distant future the only way to get serial output will be through PCI or USB. Given that USB controllers hang off the PCI bus I don't see an issue with having the serial module require the pci module. On Sat, Nov 08, 2008 at 01:45:44PM +0100, Robert Millan wrote: > On Sat, Nov 08, 2008 at 02:23:32PM +0200, Vesa J????skel??inen wrote: > > > > > > Why not use PCI ID to support this particular card? This way Donald > > > doesn't > > > have to support all cards, but the base is laid out so more cards can be > > > added > > > in the future. > > > > I have nothing against that. But in any case I think there has to be > > this override functionality support. Just make it a bit harder for user > > to type so they know it is advanced feature :). > > How about implementing the flag but not listing it in --help output, and > not documenting it (oh wait, we didn't document serial.mod anyway ;-)) ? > > > Of course you can dynamically check if PCI module is there and > > then ask identification information from there. > > Sounds good. But do we have support for "weak" symbol dependencies a la > dlym() ? > > -- > Robert Millan > > The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and > how) you may access your data; but nobody's threatening your freedom: we > still allow you to remove your data and not access it at all." > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/443-3786 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
