Date: Sun, 12 Mar 95 14:16:31 MST From: terry@cs.weber.edu (Terry Lambert) To: hsu@cs.hut.fi (Heikki Suonsivu) Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: New Cyclades driver issues and status Message-ID: <9503122116.AA08208@cs.weber.edu> In-Reply-To: <199503122030.WAA23886@shadows.cs.hut.fi> from "Heikki Suonsivu" at Mar 12, 95 10:30:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 1. FreeBSD seems to have bidir support in the device driver > > rather than at the application level. Is this the official > > policy? I.E. using /dev/cua and /dev/ttyd? > > It's traditional BSD. > > It avoids the lockfile issue for the getty program. > > ... but makes it necessary to duplicate the same functionality into all > serial drivers, which isn't too wise either. I've suggested abstracting the cannonical processing module, queue management, and device abstraction (ala SCO) to increase the amount of shared code and the treatment of serial cards as multiple controllers under a class driver (ala Julian's SCSI abstraction) before. Now I'll suggest it again. 8-). The problem is in driver writers not making their code modular or generic, which is the expedient soloution. I guess it depends on if you want a single driver working now, or all drivers working later. The device/calling unit abstraction is a necessary distinction between modem control and non-modem control drivers. If people would just use templating techniques, the problem would disappear. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503122116.AA08208>