Hi. I tested a new serial driver in a vmware with 4 serial ports. It creates only one serial device and a symbolic link to it ("COM3"); When I write to "COM3" output goes to COM1 and mix with debug output there. This is a bug imho.
Hi!
Saveliy Tretiakov a écrit :
I tested a new serial driver in a vmware with 4 serial ports. It creates only one serial device and a symbolic link to it ("COM3"); When I write to "COM3" output goes to COM1 and mix with debug output there. This is a bug imho.
This is not a bug, it's a feature ;) Serial stuff is not ready. Serial driver doesn't support reading, we don't have any serial enumerator (serenum), serial mouse driver directly reads and writes to port without using serial driver. Debug output does the same.
I'm planning to replace these drivers one after one. During this time, I don't want to break working stuff. So I decided to keep all the existing infrastructure, and create a parallel one. That's why I created COM3. COM1 uses the old stuff (direct write access to the port) COM3 uses the new serial driver, and redirects to COM1
If you have a second serial port, COM4 is also an "alias" for COM2.
Your 4 serial ports in vmware are a bit "out of norm". Most of PCs only have 2 ports. That's why I don't want to support more than the first 2 serial ports during this transition period.
Hervé
Hervé Poussineau wrote:
This is not a bug, it's a feature ;) Serial stuff is not ready. Serial driver doesn't support reading, we don't have any serial enumerator (serenum), serial mouse driver directly reads and writes to port without using serial driver. Debug output does the same.
I'm planning to replace these drivers one after one. During this time, I don't want to break working stuff. So I decided to keep all the existing infrastructure, and create a parallel one. That's why I created COM3. COM1 uses the old stuff (direct write access to the port) COM3 uses the new serial driver, and redirects to COM1
Existing infrastructure doesn't create any symbolic links to com port.(At least on my machine...) So, I can't see how we can break things by creating "COM1" alias for COM1.
COM3 and COM4 aliases still point to COM1 and COM2, and this can really break debug output and serial mouse. Just renaming symbolic links can't solve the problem. In my opinion, the right solution is to disable COM1 and COM2 at all, and make COM3 and COM4 symbolic links point to real COM3 and COM4. So, I will be able to hack on serial driver without touching debug output :)
If you have a second serial port, COM4 is also an "alias" for COM2.
I have a second serial port, but COM4 is not created...
Existing infrastructure doesn't create any symbolic links to com port.(At least on my machine...) So, I can't see how we can break things by creating "COM1" alias for COM1. COM3 and COM4 aliases still point to COM1 and COM2, and this can really break debug output and serial mouse. Just renaming symbolic links can't solve the problem. In my opinion, the right solution is to disable COM1 and COM2 at all, and make COM3 and COM4 symbolic links point to real COM3 and COM4. So, I will be able to hack on serial driver without touching debug output :)
I've got a machine at work with... hmm... 6 or 8 serial ports... something like that... I'd be happy to test it if somebody thinks it's ready. If you want I'll give you details on exactly what hardware it is when I get there today.
Be aware that it makes a difference wether you have got a so called multi serial card or several plain old serial HW. I may be wrong, but isn't 4 the limit. Due to 'reserved' ports for that kind of HW?
Royce Mitchell III wrote:
Existing infrastructure doesn't create any symbolic links to com port.(At least on my machine...) So, I can't see how we can break things by creating "COM1" alias for COM1. COM3 and COM4 aliases still point to COM1 and COM2, and this can really break debug output and serial mouse. Just renaming symbolic links can't solve the problem. In my opinion, the right solution is to disable COM1 and COM2 at all, and make COM3 and COM4 symbolic links point to real COM3 and COM4. So, I will be able to hack on serial driver without touching debug output :)
I've got a machine at work with... hmm... 6 or 8 serial ports... something like that... I'd be happy to test it if somebody thinks it's ready. If you want I'll give you details on exactly what hardware it is when I get there today.
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Robert Köpferl wrote:
Be aware that it makes a difference wether you have got a so called multi serial card or several plain old serial HW. I may be wrong, but isn't 4 the limit. Due to 'reserved' ports for that kind of HW?
It's a multi-serial card. The 4 limit for plain serial is due to reserved/limited irq if I understand correctly.
Saveliy Tretiakov a écrit :
I have a second serial port, but COM4 is not created...
Filip gave me the reason on IRC: "It's due to the root bus driver, that only enumerates the first device... We need to get ACPI working in order to enumerate the serial port."
I can't remove existing stuff for debug output and serial mouse support because enumeration needs first to be corrected.
I've committed stuff more to share my existing work and have a save of what I've done than to have a working serial driver in ReactOS.
Btw, current serial driver is only usable in very specific situations, and I've disabled it in registry.
Hervé
Hervé Poussineau wrote:
Saveliy Tretiakov a écrit :
I have a second serial port, but COM4 is not created...
Filip gave me the reason on IRC: "It's due to the root bus driver, that only enumerates the first device... We need to get ACPI working in order to enumerate the serial port."
Does this imply (serial ports on) ReactOS won't work on non-ACPI systems, or will ACPI data be faked for non-ACPI systems?
/Mike
Mike Nordell a écrit :
I have a second serial port, but COM4 is not created...
Filip gave me the reason on IRC: "It's due to the root bus driver, that only enumerates the first device... We need to get ACPI working in order to enumerate the serial port."
Does this imply (serial ports on) ReactOS won't work on non-ACPI systems, or will ACPI data be faked for non-ACPI systems?
ReactOS MUST work on non-ACPI systems. On ACPI systems, ACPI will enumerate all your serial ports, even non-standard ones. On all systems (ACPI and non-ACPI), standard serial ports will be probed to test their existence.
Hervé
ReactOS MUST work on non-ACPI systems. On ACPI systems, ACPI will enumerate all your serial ports, even non-standard ones. On all systems (ACPI and non-ACPI), standard serial ports will be probed to test their existence.
I think, to correctly enumerate com ports in this situation, you need to remove enumeration code from pnp routines. What do you think about creating something like SerialEnumerateComPorts() routine and call it from DriverEntry? If you are not working on this now, I can try to implement it. The enumeration process is described in "Enumerating Legacy COM Ports" article from DDK.
Saveliy Tretiakov wrote:
ReactOS MUST work on non-ACPI systems. On ACPI systems, ACPI will enumerate all your serial ports, even non-standard ones. On all systems (ACPI and non-ACPI), standard serial ports will be probed to test their existence.
I think, to correctly enumerate com ports in this situation, you need to remove enumeration code from pnp routines. What do you think about creating something like SerialEnumerateComPorts() routine and call it from DriverEntry? If you are not working on this now, I can try to implement it. The enumeration process is described in "Enumerating Legacy COM Ports" article from DDK.
Oops, I haven't seen your latest changes from svn. Maybe you already did it...
Saveliy Tretiakov a écrit :
I think, to correctly enumerate com ports in this situation, you need to remove enumeration code from pnp routines. What do you think about creating something like SerialEnumerateComPorts() routine and call it from DriverEntry? If you are not working on this now, I can try to implement it. The enumeration process is described in "Enumerating Legacy COM Ports" article from DDK.
Oops, I haven't seen your latest changes from svn. Maybe you already did it...
Yes, it's done. See DetectLegacyDevices() in legacy.c. This method is called at the end of DriverEntry. This is this functionality that permits detection of 2 serial ports even if ACPI enumeration and root bus enumeration don't fully work.
Hervé
-
Hervé Poussineau -
Mike Nordell -
Robert Köpferl -
Royce Mitchell III -
Saveliy Tretiakov