art@ACC.arpa (10/13/86)
I thought that I would mention something we discovered while debugging a driver for a terminal device of ours. The problem exists in (at least) BSD 4.2, BSD 4.3 and ULTRIX 1.2. Most of the terminal device drivers point the cdevsw entries for the select system call to ttselect(), which contains the following line: register struct tty *tp = &cdevsw[major(dev)].d_ttys[minor(dev)]; ^^^^^^^^^^^^^^^^^^ This code assumes that the minor device number can be used as an index into the driver's tty structure array. My understanding is that ONLY THE DRIVER should interpret the meaning and format of the minor device number. Our driver defines minor numbers which have more structure than that and caused select to break. The solution was to point cdevsw to a select entry in the driver which massaged the dev parameter and then called ttselect(). But I still object to code outside of the driver making assuptions about the format of the driver's tty structure array and minor number. <Art@ACC.ARPA> ------
chris@umcp-cs.UUCP (Chris Torek) (10/18/86)
In article <4569@brl-smoke.ARPA> art@ACC.arpa writes: >... Most of the terminal device drivers point the cdevsw entries for >the select system call to ttselect(), which contains the following line: > register struct tty *tp = &cdevsw[major(dev)].d_ttys[minor(dev)]; >This code assumes that the minor device number can be used as an index into >the driver's tty structure array. My understanding is that ONLY THE DRIVER >should interpret the meaning and format of the minor device number. The interpretation inside ttselect() is a code-saving device. The driver can override this easily. (There should be an equivalent routine that can be called with a `struct tty *'; as it is a driver has to play games with `dev', then call ttselect(). But as distributed all of the drivers could use ttselect() directly, which makes this other routine unnecessary. Writing, e.g., ttselect(dev) dev_t dev; { return (tty_select(&cdevsw[major(dev)].d_ttys[minor(dev)])); } tty_select(tp) register struct tty *tp; { ... would be cleaner, but slower; ergo, it was not done.) >Our driver defines minor numbers which have more structure than >that and caused select to break. It was your option to put `ttselect' into conf.c. . . . (It *would* be nice if ttselect's assumption were mentioned in conf.c.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
jso@edison.UUCP (John Owens) (10/21/86)
In article <4569@brl-smoke.ARPA>, art@ACC.arpa writes: > [...] ttselect() [...] contains the following line: > register struct tty *tp = &cdevsw[major(dev)].d_ttys[minor(dev)]; > This code assumes that the minor device number can be used as an index into > the driver's tty structure array. My understanding is that ONLY THE DRIVER > should interpret the meaning and format of the minor device number. [....] > But I still object to code outside of the driver making assuptions about > the format of the driver's tty structure array and minor number. I agree with the principle, but I don't see this as a violation. I would consider ttselect() to be part of the driver code; when writing your driver, you can write your own select routine, possibly calling ttselect(), or, if you understand the way ttselect() works, you can use that instead, making this generic routine logically part of your driver. Since it's up to the driver writer, and not in some part of the kernel not under the driver's control, I don't see a problem. If such dependencies were noticed and documented, the world would, of course, be a better place to write drivers in.... John Owens General Electric Company - Charlottesville, VA jso@edison.GE.COM old arpa: jso%edison.GE.COM@seismo.CSS.GOV +1 804 978 5726 old uucp: {seismo,decuac,houxm,calma}!edison!jso