sync/async [was: Re: tt_ioctl]
xcllnt at mac.com
Wed Apr 9 15:58:02 UTC 2008
On Apr 9, 2008, at 3:56 AM, Poul-Henning Kamp wrote:
> In message <18428.624.490619.248235 at gromit.timing.com>, John E Hein
>> 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
> 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.
xcllnt at mac.com
More information about the freebsd-arch