>-----Original Message----- >... >> what happens if you have 2 different PCI cards installed, > >Then serial.mod can handle multiple terminals (it already >does, just not for PCI cards) via `serial' command, and use >the PCI calls to gather info about them whenever they're to be used. >
Hmmm, this is getting a litte more complex than I had hoped but so be it. The problem is that to do this you need more than just a PCI ID to base_baud map, now you have to be able to enumerate serial devices, both multi-port and multi-function, so you can match different terminal ports to their resources. The code to do this is moderately complex but, fortunately, the code already exists in the Linux driver, I can just copy that code. I know that that code needs sub-vendor and sub-device IDs which I don't think are exposed by the current grub PCI code so I'll have to expand the PCI code just a little. My thought was that we leave units 0 - 3 as the legacy ports (whether they exist or not) and then number the PCI serial ports that we find as units 4 and up. I have a patch for a simple PCI ID to base_baud map, I'll to to work on expanding that patch. Also, I'd like to modify the `serial' command so that typing that command with no arguments lists out the serial ports availale, I think that would be a usefull capability. >> what happens if you find a serial card that isn't on the list, > >Does this issue happen with all serial cards, or just some? >If it happens with all, I guess it could just issue an error >and let the user know that we need feedback on how to add this one? > >> what about Express cards, etc. > >What do you mean? I don't know anything about Express cards, if they sit on the PCI bus with normal BDF's then there is no problem, if they interface through some other means then supporting them will get interesting. > >-- >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
