Re: Reminder: non-mpsafetty drivers to be connected on Sunday

On Friday 01 August 2008 07:39:35 am Ed Schouten wrote:
> Hi all,
>
> One month ago I sent a schedule to the lists about the MPSAFE TTY code
> I'm working on. It contained the following:
>
> * Ed Schouten <ed_at_80386.nl> wrote:
> > August 3 2008:
> > 	Disconnect drivers from the build that haven't been patched in
> > 	the MPSAFE TTY branch.
>
> This means I'm going to disconnect these drivers on Sunday. I posted a
> list of drivers some time ago. The list of drivers is a little different
> than what I had posted:
>
> - I omitted ppp(4) and sl(4) on purpose, because I expected they would
>   already have been disconnected by this time (IFF_NEEDSGIANT).
>
> - It seems I forgot to mention ucycom(4) and ufoma(4). These have not
>   been ported to the new TTY layer.
>
> This means the complete list of drivers is:
> | USB: ubser(4), ucycom(4), ufoma(4)
> | ISA/PCI: cx(4), cy(4), digi(4), rc(4), rp(4), si(4), sio(4)
> | Line disciplines: ng_h4(4), ng_tty(4), ppp(4), sl(4), snp(4)
>
> There are a couple of important things to mention here:
>
> - Some line disciplines (ng_h4(4), ng_tty(4) and snp(4)) will be
>   restored in the future. After the new TTY code has been imported, a
>   hooks interface shall be developed, which will allow these drivers to
>   work once again.
>
> - PC98 still uses the sio(4) driver. I've decided not to touch PC98 at
>   this moment. I'll contact the PC98 folks one of these days, to see if
>   we can already perform a partial migration to uart(4).
>
> Wrapping up, I'd like to say I really hope we can one day see these
> drivers reappear in FreeBSD. Fortunately we've still got a long time
> before 8.0-RELEASE.
>
> Yours,

Note that one approach you can take is that even if you can't test patches for 
some of these drivers due to ENOHARDWARE, other users can.  So you can still 
generate patches for drivers (make sure they compile) and then post them to 
current and stable to get them tested.  I think it is more courteous to our 
users that way than to require them to be developers.  And given my recent 
and continuing efforts with NIC drivers, I think I can safely say that I've 
already put my money where my mouth is on this one.  However, it is probably 
far easier to provide patches for testing once the actual subsystem is in the 
tree rather than prior, so if the plan is to do that then I'm ok with it.  
There is something to be said, however, for the model used in the network 
stack where some hack shims were left in place to support non-updated drivers 
until they could be updated.

I know I have an rp(4) card (but in use in a production box running 6.x) and 
from that I know other people also have rp(4) cards that I've talked with 
(and RocketPort even provides their own FreeBSD driver) for example.

-- 
John Baldwin