Hello! During the last week, when I didn't know I would be assigned to be the MediaKit Team leader, i did a small experiment. I tried rewriting a *compatible* kernel mode driver which would act as a /dev/ports/serial9 device. To be used as modem with net_server and SerialConnect. At first it looked easy. One open flag telling me if i should use blocking io or not, and some ioctl calls from Drivers.h and from termios.h After implementing all them, i had the first problem. termios.h ioctls are not documented properly, and are different from the ones used in *nix. The next problem was taht booting beos would hang the computer. The kernel does probe for a mouse, opens the driver in non-blocking mode, switches to blocking mode, and tries to read(). So my driver blocks, as there is no data. Also, some iocls used by net_server and SerialConnect sometimes do not have the expected argument pointer (it is null) Then, there is the ioctl TCWAITEVENT, not documented, of couse. If my driver blocks there if no data ist available, net_server will hang. Also, net_serverconstantly modified termio_data.c_cc[VEOL] using ioclts TCGETA and TCSETA. Normally, there is the "end of line" character coded, but net_Server wrote strange values like 0x00 and 0x14. Now I wrote a test program which opened /dev/ports/serial1 and did the ioctls to the real BeOS driver. I found out something interesting. I cant write() to it, I always get a return code of -1. And even in blocking-io mode, read() does not block. Onthe other hand, TCWAITEVENT does block, depending on the value in termio_data.c_cc[VEOL]. This is completely different than any existing documentation in the internet. Timeouts seem to be: termio_data.c_cc[VEOL] = 0x0; => block until data? termio_data.c_cc[VEOL] = 0x01; => .1 sec termio_data.c_cc[VEOL] = 0x0a; => 1.0 sec termio_data.c_cc[VEOL] = 0x0d; => 1.3 sec termio_data.c_cc[VEOL] = 0x14; => 2.0 sec termio_data.c_cc[VEOL] = 0x15; => 2.1 sec termio_data.c_cc[VEOL] = 0x30; => 4.8 sec I wanted to have a real simple driver, connected to a really simple test program. And I ended with reverse engineering this driver about 10 hours. And nothing works. The test program can not write to the real /dev/ports/serial1 device, so the modem will never generate data I can receive with read() On the other hand, If I connect the test program or SerialConnect to my fake device, i can see how they both successfully write data using write(), and my test program shows that write() succeeds. I could now try to use BSerialPort and use it on both device drivers, finding out what happens, but i don't have the time. Ok, this is probably not very interesting. The reason is that I was trying to do some research for ISDN driver development. but it shows some interersting difficulties. There is more, but I will stop now. regards, Marcus Overhagen