Date: Thu, 03 Jul 2008 14:09:26 -0700 From: Sam Leffler <sam@freebsd.org> To: Ed Schouten <ed@80386.nl> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Arch <arch@freebsd.org> Subject: Re: MPSAFE TTY schedule [uart vs sio] Message-ID: <486D4006.2050303@freebsd.org> In-Reply-To: <20080703205220.GW14567@hoeg.nl> References: <20080702190901.GS14567@hoeg.nl> <20080703193406.GS29380@server.vk2pj.dyndns.org> <20080703205220.GW14567@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Ed Schouten wrote:
> Hello Peter,
>
> * Peter Jeremy <peterjeremy@optushome.com.au> wrote:
>
>> On 2008-Jul-02 21:09:01 +0200, Ed Schouten <ed@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?486D4006.2050303>