Path: utzoo!utgpu!water!watmath!clyde!rutgers!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ain From: ain@s.cc.purdue.edu (Patrick White) Newsgroups: comp.sys.amiga Subject: Re: Multiple serial ports (was Re: Need help with signals) Message-ID: <1914@s.cc.purdue.edu> Date: 12 Jan 88 17:12:37 GMT References: <1359@sugar.UUCP> <3127@cbmvax.UUCP> Reply-To: ain@s.cc.purdue.edu.UUCP (Patrick White) Organization: PUCC Land, USA Lines: 40 In article <3127@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >But I do agree that DOS does provide a standard >and complete level of device abstraction, and it should be exploited in favor >of any other system, providing the translation from abstrat to concrete is >going to be a standard thing that I can do without special, inside information. I agree. Now why don't we use this to implement multiple serial ports? eg: physical devices ---------------- mulitser: origser: <-- origional ser: device renamed logical mapped to ------- --------- ser0: origser: ser: multiser:1 <-- ser: mapped to multiser port ser1: multiser:1 ser2: multiser:2 multiser:0 origser: <-- can I do this? If I can, I could also use it for creating a hierarchical file system from a bunch of separate disks. Differing hardware (and names of device drivers to drive it) can be transparent to the user if the logical name is used. This allows reassignment of ser: to another port, and programs accessing the default port without realizing it. Also eliminates the need for device drivers calling device drivers, or one device driver knowing about all hardware designs. Ok, I think this sounds nice and elegant.. anybody want to point out why it won't work (or better yet.. figure out how to get around those obstacles)? -- Pat White UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906