Re: MPSAFE TTY schedule [uart vs sio]

Ed Schouten wrote:
> Hello Peter,
>
> * Peter Jeremy <peterjeremy_at_optushome.com.au> wrote:
>   
>> On 2008-Jul-02 21:09:01 +0200, Ed Schouten <ed_at_80386.nl> wrote:
>>     
>>> + The new pseudo-terminal driver is capable of garbage collecting unused
>>>  PTY's. Because PTY's are never recycled, they are a lot more robust
>>>  (they are always initialized the same, no need to revoke() them before
>>>  usage, etc).
>>>       
>> When you say 'never recycled', does this include the PTY number?  If
>> so, long running busy systems are going to get some fairly large
>> numbers.  When will the PTY number wrap?  What is the impact on tools
>> (eg ps, w) that assume they can represent a PTY in a small number of
>> digits?  What about utmp(5) which uses PTY number in the index?
>>     
>
> PTY's are deallocated when unused, which means the PTY number is reused
> when possible. We still enfore the 1000 PTY limit, because utmp(5) only
> supports line names of eight bytes long ("pts/999\0").
>
>   
>>> - Not all drivers have been ported to the new TTY layer yet. These
>>>  drivers still need to be ported: sio(4), cy(4), digi(4), ubser(4),
>>>  uftdi(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4), rc(4), si(4),
>>>  umodem(4), dcons(4).
>>>
>>> Even though drivers are very important to have, I am convinced we can
>>> get these working not long after the code as been integrated. ...
>>> If you really care about one of these drivers,
>>> please port it to the new TTY layer as soon as possible!
>>>       
>> IMHO, this is not a reasonable approach: "Hi everyone.  I'm going to
>> break infrastructure that a whole bunch of drivers depend on.  If you
>> don't fix your drivers in the next few weeks then I'll disconnect
>> them".  Either you need to provide compatibility shims (possibly
>> temporary and not MPSAFE) or you need to be far more pro-active in
>> assisting with porting existing consumers of the TTY layer.
>>     
>
> 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.
>
>   
>>> TTY layer into our kernel. I would really appreciate it if I could get
>>> this code in before the end of the summer break, because I've got heaps
>>> of spare time to fix any problems then.
>>>       
>> That's all very nice but what about the maintainers of all the other
>> drivers that you are impacting?
>>
>>     
>>> 	sio(4) has not been ported to the new TTY layer and is very hard
>>> 	to do so.
>>>       
>> This is the only mention of how much effort is involved in porting a
>> driver to use the MPSAFE TTY layer and "very hard" is not a good start.
>> I can't quickly find any documentation on how to go about porting an
>> existing driver - definitely there are no section 9 man pages describing
>> the new API in your patchset.
>>     
>
> Well, sio(4) isn't impossible to port to the new TTY layer, but the
> first thing I noticed when I was hacking on the TTY layer during my
> internship, was that the uart(4) code was so easy to read, I only had to
> alter a single 396 line C file containing all the TTY interaction, while
> the sio(4) was somewhat (tenfold) more complex.
>
> But I just got told sio(4) is required for pc98, because uart(4) is not
> supported there. This means I'll seriously consider porting sio(4) one
> of these days. It's no biggie, even though I think someone could better
> take the effort to extend uart(4).
>   

I would suggest first investigating how difficult it is to port uart to 
pc98.  Given that we're broadening our platform support having a single 
serial driver seems preferable.

> The same with dcons(4). Even though I don't have any hardware to test it
> personally, I'll try to make sure we'll get it working in time.
>   

I believe dcons is important and there are many people that can pitch in 
on this driver so I'm less worried about it.

FWIW I'm 100% behind you on moving this stuff forward.  This is a large 
project and you cannot be expected to do it by yourself.  In the case of 
platform-specific requirements (like pc98) where you won't have access 
to equipment I think it's fair to request platform maintainers help.

>   
>> IMHO, if you can't commit fixed drivers along with the MPSAFE TTY
>> layer, a more reasonable schedule is to replace the existing TTY layer
>> with an MPSAFE TTY layer that includes compatibility shims.  If the
>> shims make things non-MPSAFE (which is likely) then warn that they
>> will be going away in (say) six months.  This gives developers a more
>> reasonable timeframe in which to update, as well as working drivers
>> whilst they adapt them.
>>     
>
> So let us take a look at the list again:
>
>   
>> sio(4), cy(4), digi(4), ubser(4), uftdi(4), nmdm(4), ng_h4(4),
>> ng_tty(4), snp(4), rp(4), rc(4), si(4), umodem(4), dcons(4).
>>     
>
> Removing the drivers which have been fixed, or will be fixed in time:
>
>   
>> cy(4), digi(4), ubser(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4),
>> rc(4), si(4).
>>     
>
> After I've committed the new TTY layer, I'm going to extend its design,
> so we can have hooks again, similar to the old line discipline idea.
> This has already been discussed. I'm also planning on reviving drivers
> like nmdm(4) and snp(4) by then. This means we've only got these
> drivers left:
>
>   
>> 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.
>
>   
digi is perhaps most important in this list but I think you should 
expect other folks to help.

    Sam