Re: MPSAFE TTY schedule

Hello Peter,

* Peter Jeremy <peterjeremy_at_optushome.com.au> wrote:
> On 2008-Jul-03 22:52:20 +0200, Ed Schouten <ed_at_80386.nl> wrote:
> >Well, even though I'd rather let other people assess me, I think I've
> >been very proactive so far. As you can see, I sent my email to the list
> >two days ago. In those two days I've fixed both umodem(4) and uftdi(4)
> >to work with the new TTY layer again.
> 
> And I don't expect you to do all the work yourself - you can't be
> expected to test hardware you don't have.  But where is the documentation
> to let someone else adapt the drivers?

Well, right now documentation on the KPI is one of the things that is
missing. As you mentioned in your first email, I am planning to add
several man9 pages, but so far I haven't found any time to write them.

I think there are already various (very small) drivers that could be
used as examples. Below is a list of files, including their size in
lines:

| 241 /sys/dev/ofw/ofw_console.c
| 181 /sys/ia64/ia64/ssc.c
| 371 /sys/sun4v/sun4v/hvcons.c

> >> cy(4), digi(4), rp(4), rc(4), si(4).
> >
> >Who actually owns one of these devices? If you do, please contact me. If
> >I didn't make myself clear enough: I *am* willing to (assist in
> >porting|port) these drivers.
> 
> I have access to a Digi Xem boards at work and have poked around
> inside the digi(4) code in the past.  My difficulty is that the cards
> are all in use and upgrading to a FreeBSD-current that doesn't support
> them and then porting the driver is probably not an option (whereas
> converting it from using shims to access the TTY layer to doing so
> directly would probably be acceptable - because I can get the board
> going again in a hurry if needed).

The problem with the old TTY layer, is that drivers tend to access the
internals of the TTY structure very often. A good example of this is the
clists, where TTY drivers tamper around inside the clist and cblock
structures. There is not much room to implement a compatibility layer
there.

The digi(4) code shouldn't be very hard to port. As I said before, I am
considering making most drivers at least compile before the code hits
the tree, which should make it a lot easier for people to get their
things working again.

Yours,
-- 
 Ed Schouten <ed_at_80386.nl>
 WWW: http://80386.nl/