Date: Wed, 9 Apr 2008 08:36:17 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org, John E Hein <jhein@timing.com> Subject: sync/async [was: Re: tt_ioctl] Message-ID: <FD6E3ED5-5315-4F39-9EF0-8C0FC1683802@mac.com> In-Reply-To: <44321.1207738604@critter.freebsd.dk> References: <44321.1207738604@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 9, 2008, at 3:56 AM, Poul-Henning Kamp wrote: > In message <18428.624.490619.248235@gromit.timing.com>, John E Hein > writes: > >> I guess I'm leaning toward a separate >> uftdi0.ctl minor device despite what the sourceforge >> linux driver does. > > That would be my inclination too. > > We had something slightly similar with a sync/async board at one > point. > > The driver never made it into the tree for a number of reasons, but > the same problem was present: We have one physical connector, and > it can either be a tty or something else. I think the complexity or problems stem from the fact that there's a single driver. With scc(4) the design is such that the driving is left to subordinate drivers like uart(4) and the only thing that scc(4) does is arbitration. The mode the hardware is in corresponds to which sub-ordinate driver is selected. As such, scc(4) presents a time-shared bus onto which multiple drivers can attach -- each of which dealing with a particular mode of the hardware. We currently only have uart(4) for async communication in the tree, but I have some sketches for drivers for bi-sync and hdlc/sdlc in P4. This approach yields logical behaviour in general. Whenever the device special file of uart(4) is being opened, uart(4) will try to activate the resources. If those resources aren't already activated (i.e. the hardware is currently idle), then uart(4) gets to use the resources and the hardware can be put in async mode. Otherwise the open will fail or block. Suppose we have a driver for sdlc/hdlc that presents a network interface. The process above is not triggered by the opening of a device, but by bringing the interface up or configuring it. This succeeds if the hardware is idle (e.g. uart(4) isn't used for async communications). I think this scheme will work well in general and should be applicable in John's case as well. JFYI, -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FD6E3ED5-5315-4F39-9EF0-8C0FC1683802>